Red Sift’s email protocol configuration guide

image
Explore our guide

DNS setup instructions by Email Service Provider

In this chapter, we provide guidance on how to create TXT records, as well as specific DNS setup instructions for some of the most popular ESPs - from Mailbox Providers (MBPs) like Gmail and Microsoft to Shopify and Squarespace, through to CRMs such as Salesforce and Hubspot.

TXT record creation guidance

How to create TXT records for SPF & DMARC with Amazon Route 53

  1. Log in to your Route 53 Console.
  2. In the navigation pane, choose 'Hosted zones'.
  3. Choose the domain that you want to add a TXT or CNAME record to.
  4. Choose 'Create record'.
  5. For 'Routing policy, choose Simple routing, and then choose Next.
  6. Choose Define simple record.
  7. In the Define simple record pane, do the following:
  8. - For Record name, Enter the host name for the TXT record. For example, leave this blank for an SPF record, or enter the value _dmarc for a DMARC record.
  9. - For Value/Route traffic to, paste the value you are setting as the destination of the Host or the text value of the TXT.
  10. - For Record type, choose TXT or CNAME as appropriate.
  11. - For TTL (seconds), type 1800.
  12. - Choose Define simple record.​
  13. Allow up to 24 hours for propagation of the newly created record.​

For more information on adding TXT records to your domain’s Route53 DNS server, click here.

How to create TXT records for SPF & DMARC with Azure DNS

  1. Sign in to the Azure portal with your Azure account.​
  2. Create a DNS zone (If a DNS zone for the domain is already created, skip to step 3.)
  3. At upper left, select Create a resource, then Networking, and then DNS zone.
  4. On the Create DNS zone page, type or select the following values:
  5. Name: Type contoso.xyzcontoso.xyz for this quickstart example. The DNS zone name can be any value that is not already configured on the Azure DNS servers. A real-world value would be a domain that you bought from a domain name registrar.
  6. Resource group: Select Create new, enter MyResourceGroup, and select OK. The resource group name must be unique within the Azure subscription.
  7. Select Create.
  8. Create a DNS record
  9. In the Azure portal, under All resources, open the contoso.xyzcontoso.xyz DNS zone in the MyResourceGroup resource group. You can enter contoso.xyzcontoso.xyz in the Filter by name box to find it more easily.
  10. At the top of the DNS zone page, select + Record set.
  11. On the Add record set page, type or select the following values:
  12. Host: Enter the host name for the TXT record. For example, enter @ for an SPF record, or enter the value _dmarc for a DMARC record.
  13. Type: TXT
  14. Value: The value you are setting as the destination of the Host.
  15. TTL: Determine how long the server should cache information.​
  16. Click 'Save' to publish the newly created record.

For more information on creating DNS records using Azure DNS, click here

How to create an SPF record in DNS using Cloudflare

For this scenario, we will use G Suite as the sending service and our domain would be test.ondmarc.com. ​ To authorize G Suite to send emails on behalf of our domain we need to create the following SPF record in DNS.

v=spf1 include:_spf.google.com ~all

How to create the SPF record

Now that we have the value for our SPF record that needs to be created let’s go ahead and add it to the DNS for test.ondmarc.com in Cloudflare.

1. Log in to Cloudflare.

2. Select the account under which your domain exists.

3. Select the domain (ondmarc.com) under which you would like to create the SPF record.

4. Click the DNS app from the row of apps.

5. You will be presented with the following UI. Create and fill in the fields as shown at the beginning of this article.

imageimage
  • The record type is TXT
  • The name of the record in this case would be test.ondmarc.comtest.ondmarc.com
  • The value portion of the record above contains the following:
​v=spf1 include:_spf.google.com ~all

We will leave the TTL set to Automatic and click Add Record.

Please allow some time for the record to propagate and be detected.

How to create TXT records for SPF & DMARC with Fasthosts

  1. Log into your FastHosts account. 
  2. Under the Domain menu click Manage Domains.
  3. Select the domain name from the list that you wish to add the DNS records to.
  4. Click into the Configure Advanced DNS link.
  5. A list of DNS records will be shown.
  6. Scroll Down the list and click on the blue icon "ADD TXT RECORD"
  7. Fill out the fields with the following info: a) Hostname: Enter the host name for the TXT record. For example, enter @ for an SPF record, or enter the value _dmarc for a DMARC record. b) Destination TXT Value: The value you are setting as the destination of the Host.
  8. When the information are entered, click Save.

For more information on managing DNS in Fasthosts, click here.

How to create TXT records for SPF & DMARC with Google Domains

  1. Log in to your Google Domains account, select your 'Domain', and go to the 'DNS' section.
  2. Scroll down to the 'Custom resource records' and create the following record(s):
  3. SPF Record:
  4. Name: For the SPF record, enter the host name. Typically, you can use "@" to indicate the root domain.
  5. Type: Select TXT as the record type.
  6. Data: Enter the value for your SPF record. This value specifies which email servers are authorized to send emails on behalf of your domain.
  7. TTL: Determine the Time-to-Live for the record. This dictates how long DNS servers should cache the information.
  8. DMARC Record:
  9. Name: For the DMARC record, use the host name _dmarc.
  10. Type: Select TXT as the record type.
  11. Data: Set the value for your DMARC record. This value defines the DMARC policy and how email receivers should handle emails that fail authentication checks.
  12. TTL: Set the appropriate Time-to-Live value for the DMARC record.
  13. Click 'Add' to publish the new record.

How to create TXT records for SPF & DMARC with Hover

  1. Sign in to your Hover account.
  2. If you have multiple domain names, choose the domain name you want to edit.​
  3. Select the 'DNS' tab.
  4. Select 'Add New' and enter the following:
  5. Host: Enter the host name for the TXT record. For example, leave the host blank for an SPF record, or enter the value _dmarc for a DMARC record.
  6. TXT Value: The value you are setting as the destination of the Host.
  7. TTL: Determine how long the server should cache information.​
  8. Select Save.​

For more information on managing DNS records with Hover, click here.

How to create TXT records for SPF & DMARC with Ionos (Formerly 1&1)

  1. Log in to IONOS.
  2. For the desired domain, click on the gear symbol under Actions and select DNS.
  3. Click Add Record and select TXT under Type.
  4. In the Host name field, specify the desired host, For example, enter @ for an SPF record, or enter the value _dmarc for a DMARC record.
  5. In the Value field, paste the value you are setting as the destination of the Host (i.e. the value of the SPF or DMARC record to be used).
  6. Optional: Select the desired TTL (Time to Live). By default, your settings are immediately active.
  7. Click Save. The TXT record has now been added.

For more information on adding TXT records in Ionos, click here.

How to create TXT records for SPF & DMARC with Namecheap

  1. Login to your Namecheap Account, choose 'Domain List' on the left, and click on the 'Manage' button next to your domain.
  2. Navigate to the 'Advanced DNS' tab from the top menu and click on the 'Add new record' button.​
  3. Select TXT Record for 'Type'.
  4. Host: Enter the hostname for the TXT record. For example, leave the host blank for an SPF record, or enter the value _dmarc for a DMARC record.
  5. TXT Value: The value you are setting as the destination of the Host.
  6. TTL: Determine how long the server should cache information.

​NOTE: The domain name itself should not be included in the Host field. It means that if you need to add the record for dmarc.yourdomain.tld, dmarc.yourdomain.tld, only dmarcdmarc is to be added as a Host value. For more information, click here.​

How to create TXT records for SPF & DMARC with Network Solutions

  1. Log in to your Network Solutions Account Manager.​
  2. Enter the username and password you created when you purchased your domain from Network Solutions.
  3. Click Login.
  4. From the Network Solutions Account Manager, under My Domain Names, click 'Edit DNS'.
  5. Click 'Change Where Domain Points'.​
  6. Select 'Advanced DNS' and click 'Continue'.​
  7. Open the instructions for the type of DNS record you want to add for your domain. (TXT steps included below)
  8. Host: Enter the host name for the TXT record. For example, enter @ for an SPF record, or enter the value _dmarc for a DMARC record.
  9. TXT Value: The value you are setting as the destination of the Host.
  10. TTL: Determine how long the server should cache information.
  11. Scroll down and click 'Continue'.​
  12. Click 'Save Changes' to publish the record.

For more information on managing DNS records with Network Solutions, click here.

How to create TXT records for SPF & DMARC with 123Reg

  1. Login to your 123Reg Control Panel.
  2. Search your Domain Name next to DOMAINS and Click on MANAGE.
  3. Scroll down to Advanced Domain Settings and click on Manage DNS (A, MX, CNAME, TXT, SRV).
  4. Click on the Advanced DNS tab.
  5. Select TXT or CNAME as the Type and fill out the fields with the following info: a) Hostname: Enter the host name for the TXT/CNAME record. For example, enter @ for an SPF record, or enter the value _dmarc for a DMARC record. b) Destination TXT Value: The value you are setting as the destination of the Host.
  6. When the information is entered, select Add.

For more information on managing DNS records in 123Reg, click here.

DNS setup instructions

AppRiver SPF and DKIM set up

SPF

AppRiver was bought by Zix, so your SPF record will depend on which product you have.

For more information on SPF at Zix, please click here.

DKIM

For more information on enabling DKIM, please contact AppRiver support.

Brevo (formerly Sendinblue) SPF and DKIM set up

Increase the deliverability of your Brevo (formerly Sendinblue) emails by correctly configuring SPF and DKIM.

SPF

Adding SPF for Brevo (formerly Sendinblue) for DMARC purposes is not needed because the Return-Path address of the emails is set to their default domain in order to track bounces on your behalf. Therefore, SPF will not pass for Brevo from a DMARC perspective, however, as long as DKIM passes, the emails will be DMARC compliant.

DKIM

To enable DKIM you will have to create a few DNS records. Please follow the instructions using the button below for more information.

Google Workspace SPF and DKIM set up

SPF

To authorize Google to send emails on your behalf you will need to create an SPF record that includes the following value:

include:_spf.google.com <-- this part allows all Gsuite IPs to send emails on your behalf.

If you already have an existing SPF record you will just have to copy the include include:_spf.google.com and append it to your current SPF record, however, it has to be put after the v=spf1 and before the ~all ending mechanism in your record.

If you already have an existing SPF record such as:

v=spf1 include:mail.zendesk.com ~all

and you would like to add Gsuite as an additional sending service, you will have to copy the include include:_spf.google.com and append it to your current SPF record. 

The final SPF record should look like this:

v=spf1 include:mail.zendesk.com include:_spf.google.com ~all

Do not create a second SPF record if you already have one. You should only have one SPF record per domain/subdomain.

To learn more about SPF and how to configure it for Google Workspace please click here.

DKIM

To implement DKIM for your domain you will have to follow the steps below.

  1. Log in as administrator and go to the Admin Console.
  2. Go to Apps --> G Suite
  3. Click on the Gmail app.
  4. Click on Authenticate email
  5. For the key length you can choose between 1024 or 2048. The longer the key the better, however, some DNS providers do not support keys longer than 1024. They should be able to implement 2048 as well but there may be some additional work that needs to be carried out.
  6. Select your prefix selector, you can leave the default of "google" or type in your own. This will be your DKIM selector.
  7. Once the key is generated, you will need to take the information provided and put it in your DNS ie. create the TXT record. It will look like the example below, except that you will have to replace the word "selector" below with the one that you created earlier.

Type

Host

TXT value

TTL

TXT

selector._domainkey

Paste the key generated here

1 hour (default)

NOTE: it may take up to 48 hours for the DNS changes to propagate.

Also, you can't add a custom DKIM selector for 24 hours.

For more information please click here.

Hubspot SPF and DKIM set up

SPF

Adding SPF for Hubspot for DMARC purposes is not needed because the Return-Path address of the emails is set to Hubspot's default domain in order to track bounces on your behalf. Therefore, SPF will not pass for Hubspot from a DMARC's perspective, however, as long as DKIM passes, the emails will be DMARC compliant.

DKIM

For information on how to configure DKIM and add the necessary DNS records please click here.

Kajabi SPF and DKIM set up

As Kajabi constantly updates its documentation, please click here for the most accurate information.

Klaviyo SPF and DKIM set up

To authorize Klaviyo to send emails on your behalf and customize those emails to match your domain you will have to carry out full domain whitelabeling. During this process, you will be provided with the necessary DNS records that need to be created so your emails start passing SPF and DKIM. 

For more information and instructions on how to complete the full whitelabeling process please click here

Mailerlite SPF and DKIM setup

Mailerlite provides two ways of authenticating your domain. They can either manage the authentication for you or allow you to manage it yourself. If you let Mailerlite authenticate your emails then your receivers would see Mailerlite as the sender of your emails. If you would like your receivers to see your domain only then you will have to choose the option to authenticate emails yourself. 

Configuring SPF and DKIM with Mailerlite for your custom domain is pretty easy. All you have to do is choose Authentication, insert your domain and select Show DNS record.

The necessary SPF and DKIM records will be generated and presented to you which you will then have to add to your DNS. For more information please click here.

Once you have created SPF and DKIM but still showing as inactive in your account, please click here for information on how to troubleshoot this.

Mandrill SPF and DKIM setup

Mandrill is a product created by Mailchimp and is a service used to send transactional emails. To improve your email deliverability, Mandrill requires that every domain of yours is configured with SPF and DKIM.

SPF

To allow Mandrill to send emails on your domain’s behalf, you must include them as part of your SPF record. 

The SPF mechanism used by Mandrill is the following:

include:spf.mandrillapp.com

Mandrill uses their own domain as part of the Return-Path address (used by SPF) and hence SPF alignment would not occur. However, this can be modified as per their help article.

For more information, visit the Mandrill help article.

DKIM

To set up DKIM for Mandrill, you will need to add a new TXT record in your DNS.

The name for the TXT record should be: 

mandrill._domainkey.yourdomain.comReplace “yourdomain.com” above with the domain you are setting up.

The value of the DNS record should be the following:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrLHiExVd55zd/IQ/J/mRwSRMAocV/hMB3jXwaHH36d9NaVynQFYV8NaWi69c1veUtRzGt7yAioXqLj7Z4TeEUoOLgrKsn8YnckGs9i3B3tVFB+Ch/4mPhXWiNfNdynHWBcPcbJ8kjEQ2U8y78dHZj1YeRXXVvWob2OaKynO8/lQIDAQAB;

After you have added the required DNS records, you can use the Test the DNS Settings button in your control panel to make sure that everything that you have added has a green checkmark. Please allow 24-48 hrs for the DNS changes to take effect. 

For more information, visit the Mandrill help article.

Mimecast DKIM signing setup

To setup DKIM signing in Mimecast you need to create a definition and a policy.

Setting up a definition

  1. Login to Mimecast
  2. Select Administration console
  3. From the top left select Administration > Gateway > policies
  4. Select definitions drop down select DNS Authentication - Outbound
  5. Select New DNS Authentication - Outbound signing
  6. Set a name for the definition
  7. Tick the checkbox Sign outbound mail with DKIM
  8. Use the lookup option to select domain to DKIM sign
  9. Select generate
  10. Create a TXT record within your DNS with the public key provided save and exit
  11. Verify public key in Mimecast console

Setting up a policy

  1. Login to Mimecast
  2. Select Administration Console
  3. From the top left select Administration > Gateway > policies
  4. Search for DNS authentication outbound
  5. Select New Policy
  6. Name the policy
  7. Under emails from use address based on "Both"
  8. Save and Exit

Microsoft Dynamics 365 SPF and DKIM set up

SPF

To authorize Microsoft Dynamics 365 to send emails on your behalf, you must include it in your SPF record. The SPF record mechanism used for Microsoft Dynamics 365 is shown below. Find more information here.

include:marketing.dynamics.com

​DKIM

Microsoft Dynamics 365 supports DKIM signing for your custom domain. For more information on how to set it up please click on the button below. Find more information here.

Microsoft Office 365 SPF and DKIM set up

Set up your SPF record for Office 365

To authorize Microsoft 365 (formerly Office 365) to send emails on behalf of your domain you will have to add it to your SPF record. The SPF record mechanism used for Microsoft 365 is: 

include:spf.protection.outlook.com <-- this part allows all Office 365 IPs to send emails on your behalf.

If Microsoft 365 is your only legitimate source of emails, your SPF record should look like the below example:

v=spf1 include:spf.protection.outlook.com ~all

If you already have an existing SPF record such as:

v=spf1 include:mail.zendesk.com ~all

and you would like to add Office 365 as an additional sending service, you will have to copy the include include:spf.protection.outlook.com and append it to your current SPF record. The final SPF record should look like this:

v=spf1 include:mail.zendesk.com include:spf.protection.outlook.com ~all

However, do not create a second SPF record if you already have one. You should only have one SPF record per domain/subdomain.

I get a warning from Microsoft 365 when using Dynamic SPF

If you are using Dynamic SPF and you also use Microsoft 365 for email, you may have noticed that Microsoft will give you a warning about your SPF include being incorrect.

domain status imagedomain status image

This is expected and you can safely ignore it. Microsoft is looking for the literal string they provide in your DNS and does not know that their IP ranges are already included in Dynamic SPF.

You can test Dynamic SPF is working correctly by sending a test email to the address listed in the Investigate section of the OnDMARC console.

Set up your DKIM for Office 365

In order to DKIM sign your custom domain emails you will need to complete the following steps.

Creating the CNAME records

The CNAME records are used to map an alias name to the true or canonical domain name. In essence, when you provision a new domain name in Microsoft 365 you will need to create two CNAME records for it so that it points to your initial domain. 

We will use example.onmicrosoft.com as our initial domain, also called the tenant domain. But we actually own example.com and after we provision it in Office 365 we need to publish the two CNAME records so that example.com points to example.onmicrosoft.com using the format below.

Please note that if you are a Microsoft 365 US Government Cloud (GCC) customer, the domainGUID method below will not work for you. You will need to use the proper MX value for your domain. Example: 

selector1-<domain-key>._domainkey.<initialDomain> 

Use this article to find the MX record needed for your domain-key value.

Host name: selector1._domainkey.<domain>
Points to address or value: selector1-<domainGUID>._domainkey.<initialDomain>
TTL: 3600
Host name: selector2._domainkey.<domain>
Points to address or value: selector2-<domainGUID>._domainkey.<initialDomain>
TTL: 3600

In our example the CNAME records will look like this:

Host name: selector1._domainkey.example.com
Points to address or value: selector1-example-com._domainkey.example.onmicrosoft.com
TTL: 3600
Host name: selector2._domainkey.example.com
Points to address or value: selector2-example-com._domainkey.example.onmicrosoft.com
TTL: 3600

Please pay close attention to the domainGUID which does not use a full stop "." but a dash "-" instead. This is taken from the MX record of your custom domain, in this case, example.com.example.com.

The reason behind the two CNAME records is that Microsoft rotates the two keys for added security.

Enabling DKIM signing

Once you have added the CNAME records (two per domain) DKIM signing can be enabled through the Microsoft 365 Security admin center at http://security.microsoft.com/dkimv2

For more information on how to configure DKIM in Office 365 please click here

Namecheap Private Email SPF and DKIM set up

SPF

To authorize Namecheap Private Email to send emails on your behalf you will have to include it in your SPF record. The SPF record mechanism used is shown below.

include:spf.privateemail.com 

For more information on SPF set up for Namecheap Private Email please click here

DKIM

For instructions on how to set up DKIM, please click here

Proofpoint Protection Server (PPS) SPF and DKIM setup

SPF

To authorize Proofpoint to send emails on your behalf, you must include it in your SPF record. Refer to your Deployment Information email for the details, as the SPF is unique to each PPS cluster.

It usually follows the format:

 include:spf-{clusterid}.pphosted.com

DKIM

To set up DKIM on PPS, follow these steps:

  1. Navigate to Email Protection tab > Email Authentication > DKIM Signing > Keys
  2. Click Generate Key to create a key for a domain and selector. Each key must have a unique domain and a unique selector within the domain. Proofpoint-generated domain keys are 2048-bits in length.
  3. At the Generate Key Entry dialog box type or specify your domain, the selector, the scope of the key, and the policy routes. ​ For the policy routes, only check Disable processing for selected policy routes… Under Available scroll down and select default_inbound Click the >> to add it to Disable For Any Of:
  4. Click on Add Entry.
  5. Click View in the DNS Text Record column to see the text record for a DKIM key.
  6. A pop-up window displays the DNS text record that contains the public key. Copy the DNS text record for each domain-selector pair to your DNS servers
  7. Once the DNS record has been created, wait a few minutes to ensure the record has time to propagate.
  8. On the PPS Admin Console and click on Test to verify if the DNS record was created correctly.
  9. The feedback for the test will appear above the navigation tabs (System, Email Protection, Information Protection).
  10. Once the DNS record has been validated click the Enabled box and then click Save Changes.
  11. Turn on DKIM Signing by navigating to Email Protection tab > Email Authentication > DKIM Signing > General
  12. Click On next to Enable
  13.  Click Save Changes

For more details or detailed screenshots, refer to the Proofpoint documentation here.

Salesforce Marketing Cloud SPF and DKIM set up

SPF

To authorize Marketing Cloud to send emails on your behalf you will have to include it in your SPF record. The SPF record mechanism used for Marketing Cloud is shown below. Found out more here.

include:cust-spf.exacttarget.com

DKIM

If you have the Sender Authentication Package you will be able to enable DKIM. Please contact your account manager at Marketing Cloud for more information.

Shopify SPF and DKIM record set up

What is the SPF record mechanism and DKIM selectors used by Shopify that I need to configure in DNS?

SPF

To allow Shopify to send emails on your behalf you will have to add it to your SPF record. The SPF record mechanism used for Shopify is shown below.

include:shops.shopify.com

DKIM

To set up DKIM for Shopify, you can authenticate your domain by clicking Authenticate on the Sender email page of your Shopify admin console. A new window will open and provide you with instructions on how to create four new records with your domain provider.

Custom domain settings for Shopify

Squarespace SPF and DKIM set up

SPF

To allow Squarespace to send emails on your behalf, you will have to add them to your SPF record. The SPF mechanism used by Squarespace is shown below.

include:squarespace-mail.com

DKIM

For DKIM support, you need to create a CNAME record in your DNS. It should have the following properties:

Host: squarespace._domainkeyValue: squarespace-domainkey.squarespace-mail.com​For more information please click here. 
email set up imageemail set up image
Email set up correctly? Find out free in under a minute

Frequently asked questions: Email protocol configuration guide

What is the difference between SPF hard fail (-all) and soft fail (~all), and which should I use in 2026?

In a pre-DMARC era, SPF records commonly used the "-all" mechanism to strictly enforce sender policies. However, current industry guidance in 2026 favours "~all" to balance security and deliverability, avoiding unnecessary rejection of valid emails that might fail SPF but pass DKIM and DMARC.

This is because "~all" when implemented in combination with DMARC (at p=reject) will still reject unauthenticated mail if SPF and DKIM fail, but does not block legitimate mail, thus enhancing overall email deliverability.

The DMARC specification (RFC 7489) states that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Use "-all" for inactive, non-email sending domains only (domains that send no emails at all). DMARC ignores the nuances of soft fail and hard fail in SPF configuration, treating them as SPF failures.

How does DMARC alignment work and what is the difference between strict and relaxed alignment?

DMARC does not only require SPF or DKIM to PASS but it also requires at least one of the domains used by SPF or DKIM to align with the domain found in the From header. Proper alignment is critical for email deliverability in 2026, as major inbox providers enforce these requirements.

In the case of SPF, identifier alignment means that the MAIL FROM/Return-PATH check has to PASS and also the domain portion of the MAIL FROM/Return-PATH has to align with the domain found in the From address. In strict alignment, the domains have to match exactly, whereas in relaxed alignment subdomains are also allowed as long as they come from the same organisational domain.

For example, if MAIL-FROM/RETURN-PATH is @ondmarc.com and From header is @knowledge.ondmarc.com, in strict alignment they are not aligned. However, in relaxed alignment mode, DMARC would pass.

What are DMARC aggregate reports and forensic reports, and how do they differ?

A DMARC aggregate report contains information about the authentication status of messages sent on behalf of a domain. It is an XML feedback report designed to provide visibility into emails that passed or failed SPF and DKIM. The report provides domain owners with precise insight into which sources are sending on your behalf and the disposition of those emails (the policy that was applied by the receiver).

Recipients will look at the 'rua' tag of your DMARC record and send reports there. You can specify the aggregate reporting interval by using the ri tag in your DMARC record (by default, this is set to 86400 seconds which equates to 24 hours). Forensic reports contain more detailed information about individual authentication failures. Any personally identifiable information (PII) is removed, but information that will help in troubleshooting the DMARC failure is included, such as SPF and DKIM header failure information, the entire From address, and the Subject of the email.

The address to receive Forensic DMARC reports is specified by the 'ruf' tag in your DMARC record. Not all receiving systems support sending forensic reports. Red Sift OnDMARC is one of the only DMARC applications on the market that receives forensic reports thanks to its partnership with Yahoo.

What are SPF macros and why might they cause deliverability issues?

An SPF macro refers to a mechanism used in SPF records to define reusable sets of IP addresses. SPF macros enhance the flexibility and maintainability of SPF records by allowing you to define complex sets of IP addresses in a single mechanism, which can then be referenced within multiple SPF records. For example, instead of listing individual IP addresses for each authorised email server, you can define a macro like "%{i}" which calls the sender IP of the email. Managing SPF this way allows you to control a large list of IPs without hitting the SPF lookup limit, and also obscures which IPs you approve for public querying.

However, depending on how the SPF record with macros is structured, the lack of macro expansion could result in SPF failures or 'Neutral' results (denoted by the ?all mechanism). If SPF macros play a critical role in authorising legitimate sending servers, emails might be more likely to fail SPF checks or be marked as suspicious by email receivers that rely on SPF for authentication.

What is MTA-STS and how should it be deployed to avoid blocking email delivery?

Mail Transfer Agent Strict Transport Security (MTA-STS) is a standard that enables the encryption of messages being sent between two mail servers. It specifies to sending servers that emails can only be sent over a Transport Layer Security (TLS) encrypted connection which prevents emails from being intercepted by cybercriminals.

MTA-STS adoption has grown significantly, with organisations in 2026 recognising transport layer security as essential for protecting email in transit. For receiving domains to enable MTA-STS, they must announce that they support MTA-STS in their DNS and publish a policy configuration file on their website.

Activating MTA-STS must be done carefully to mitigate blocking emails from being delivered. MTA-STS should first be deployed in testing mode, allowing time for TLS reports to provide insight into any errors that need fixing before progressing to the final enforce stage. This phased approach will likely become standard practice in 2026 for organisations implementing transport security.

What is TLS-RPT and how does it work with MTA-STS?

SMTP TLS Reporting (or TLS-RPT for short) enables reporting of TLS connectivity problems experienced by the sending MTAs and is defined in RFC8460. Much like DMARC, TLS-RPT relies on emailed reports to notify domain owners when delivery fails due to TLS issues. These reports include detected MTA-STS policies, traffic statistics, unsuccessful connections, and failure reasons.

With Red Sift OnDMARC's MTA-STS feature, you don't need to worry about complex deployment. Simply add the MTA-STS Smart Records OnDMARC provides to your DNS and Red Sift does all the hard work such as hosting the MTA-STS policy file, maintaining the SSL certificate, and flagging any policy violation through the TLS report. Modern DMARC platforms in 2026 increasingly include hosted MTA-STS as a standard feature, simplifying transport security deployment.

What is DANE and how does it differ from MTA-STS?

Published under RFC 7671, DANE (DNS-based Authentication of Named Entities) introduces a new Internet standard for setting up TLS communication between a client and a server, without having to rely on trusted Certificate Authorities (CAs).

The traditional CA model TLS has depended on allows any CA to issue a certificate for any domain. DANE does things differently by relying on the DNSSEC infrastructure (Domain Name System Security Extensions) to bind a domain name to a certificate. DANE makes use of the already existing DNSSEC protocol to make sure the data it receives is authentic and has not been tampered with.

DANE also introduces a new DNS RR type called TLSA which helps to signal to the client that a server supports TLS. The recommendation is to implement both MTA-STS and DANE. DANE is a requirement from many governments, so public agencies in the EU are often required to implement it.

DANE and MTA-STS help only if the sender supports it, however, many senders only support one or the other so implementing both improves security overall. Organisations in 2026 often deploy MTA-STS first for broader compatibility, then add DANE for enhanced security where required.

What is the purpose of the DMARC subdomain policy (sp tag) and how should it be used?

The subdomain policy allows domain administrators to protect different domains and subdomains based on how far they are along the DMARC journey. For example, if all your email-sending services sending emails on behalf of your top-level domain are fully configured with SPF and DKIM, that means that you can protect your top-level domain with a DMARC policy of p=reject whilst keeping the subdomains in p=none, and vice versa.

Also, if you have an email-sending service that is non-DMARC compliant (does not support SPF or DKIM), you may decide to assign a subdomain to it and have that subdomain in a different DMARC policy, without preventing you from protecting your other domains. This allows you to split the traffic across different subdomains and protect each one separately.