Guida alla configurazione dei protocolli email di Red Sift

Pubblicato il:30 settembre 2025
Ultima modifica:1 aprile 2026
Capitolo:21 min di lettura
Guida:80 min di lettura
image
Esplora la nostra guida

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

Domande frequenti: Guida alla configurazione dei protocolli email

Qual è la differenza tra SPF hard fail (-all) e soft fail (~all) e quale dovrei utilizzare nel 2026?

In un'epoca pre-DMARC, i record SPF utilizzavano comunemente il meccanismo "-all" per applicare in modo rigoroso le policy dei mittenti. Tuttavia, le attuali linee guida del settore nel 2026 favoriscono "~all" per bilanciare sicurezza e deliverability, evitando il rifiuto non necessario di email valide che potrebbero fallire SPF ma superare DKIM e DMARC.

Questo perché "~all" se implementato insieme a DMARC (in p=reject) continuerà comunque a rifiutare le email non autenticate se falliscono sia SPF che DKIM, ma non blocca la posta legittima, migliorando così la deliverability complessiva.

La specifica DMARC (RFC 7489) afferma che un prefisso "-" su un meccanismo SPF del mittente, come "-all", potrebbe far scattare il rifiuto della mail troppo presto, prima che il processo DMARC abbia luogo. Usa "-all" solo per domini inattivi o che non inviano email (domini che non inviano alcuna email). DMARC ignora le differenze tra soft fail e hard fail nella configurazione SPF, trattandoli entrambi come insuccessi SPF.

Come funziona l'allineamento DMARC e qual è la differenza tra strict e relaxed alignment?

DMARC non richiede solo che SPF o DKIM abbiano esito positivo, ma anche che almeno uno dei domini usati da SPF o DKIM sia allineato con il dominio trovato nell’header From. Un corretto allineamento è fondamentale per la deliverability delle email nel 2026, poiché i principali provider di caselle di posta applicano questi requisiti.

Nel caso di SPF, l’allineamento identifica che il controllo MAIL FROM/Return-PATH debba avere esito positivo e anche che la parte di dominio del MAIL FROM/Return-PATH sia allineata con il dominio trovato nell’indirizzo From. In modalità strict, i domini devono corrispondere esattamente, mentre in modalità relaxed sono ammessi anche i sottodomini purché appartengano allo stesso dominio organizzativo.

Ad esempio, se MAIL-FROM/RETURN-PATH è @ondmarc.com e l’header From è @knowledge.ondmarc.com, in allineamento strict non sono allineati. Tuttavia, in modalità relaxed, DMARC considererebbe la verifica superata.

Cosa sono i report aggregati e i report forensi DMARC e qual è la differenza?

Un report aggregato DMARC contiene informazioni sullo stato di autenticazione dei messaggi inviati per conto di un dominio. Si tratta di un feedback XML progettato per offrire visibilità su quali email hanno superato o fallito SPF e DKIM. Il report offre al proprietario del dominio una visione precisa di quali fonti inviano email per suo conto e della disposizione di tali email (la policy applicata dal ricevente).

I destinatari verificheranno il tag 'rua' del tuo record DMARC e invieranno i report lì. Puoi specificare l'intervallo di generazione dei report aggregati usando il tag ri nel tuo record DMARC (di default è impostato a 86400 secondi, cioè 24 ore). I report forensi contengono informazioni più dettagliate su singoli fallimenti di autenticazione. Qualsiasi informazione personale identificabile (PII) viene rimossa, ma vengono inclusi dati utili al troubleshooting del fallimento DMARC, come info su fallimenti SPF e DKIM, l’intero indirizzo From e l’Oggetto dell’email.

L’indirizzo per ricevere i report forensi DMARC viene specificato tramite il tag 'ruf' nel record DMARC. Non tutti i sistemi riceventi supportano l’invio di report forensi. Red Sift OnDMARC è una delle poche applicazioni DMARC sul mercato a ricevere report forensi grazie alla partnership con Yahoo.

Cosa sono le macro SPF e perché potrebbero causare problemi di deliverability?

Una macro SPF è un meccanismo utilizzato nei record SPF per definire insiemi riutilizzabili di indirizzi IP. Le macro SPF aumentano la flessibilità e la manutenzione dei record SPF, permettendoti di definire insiemi complessi di IP in un singolo meccanismo, che può poi essere richiamato in più record SPF. Ad esempio, invece di elencare singolarmente tutti gli IP autorizzati, puoi definire una macro come "%{i}", che richiama l’IP del mittente dell’email. Gestendo SPF in questo modo, puoi controllare una lunga lista di IP senza superare il limite di lookup e anche nascondere gli IP autorizzati a chi fa query pubbliche.

Tuttavia, a seconda di come è strutturato il record SPF con le macro, la mancanza di espansione delle macro può causare insuccessi SPF o risultati "Neutral" (indicati dal meccanismo ?all). Se le macro SPF sono critiche per autorizzare server di invio legittimi, l’email potrebbe più facilmente fallire i controlli SPF o essere segnalata come sospetta dai riceventi che si basano su SPF per l’autenticazione.

Cos’è MTA-STS e come va implementato per evitare blocchi nella consegna delle email?

Mail Transfer Agent Strict Transport Security (MTA-STS) è uno standard che consente la crittografia dei messaggi inviati tra due server di posta. Specifica ai server mittenti che le email possono essere inviate solo tramite una connessione crittografata Transport Layer Security (TLS), impedendo così che possano essere intercettate da cybercriminali.

L’adozione di MTA-STS è cresciuta significativamente, con le organizzazioni che nel 2026 riconoscono la sicurezza del trasporto come essenziale per proteggere le email in transito. Per abilitare MTA-STS, i domini riceventi devono annunciare il supporto a MTA-STS tramite DNS e pubblicare un file di configurazione della policy sul proprio sito web.

L’attivazione di MTA-STS va eseguita con cautela per evitare il blocco della consegna delle email. Si dovrebbe prima implementare MTA-STS in modalità test, permettendo ai report TLS di evidenziare eventuali errori da correggere prima di passare alla modalità enforcement definitiva. Questo approccio graduale diventerà probabilmente pratica standard nel 2026 per le organizzazioni che implementano la sicurezza del trasporto.

Cos’è TLS-RPT e come funziona con MTA-STS?

SMTP TLS Reporting (o TLS-RPT) consente la reportistica dei problemi di connettività TLS riscontrati dai server mittenti (MTA) ed è definito nella RFC8460. Proprio come DMARC, TLS-RPT invia report via email per notificare ai proprietari di dominio eventuali problemi di consegna dovuti a TLS. Questi report includono policy MTA-STS rilevate, statistiche sul traffico, connessioni non riuscite e motivi dei fallimenti.

Con la funzionalità MTA-STS di Red Sift OnDMARC, non devi preoccuparti di un’implementazione complessa. Basta aggiungere gli Smart Records MTA-STS forniti da OnDMARC al tuo DNS e Red Sift si occuperà di tutto il lavoro, come ospitare il file di policy MTA-STS, mantenere il certificato SSL e segnalare eventuali violazioni della policy tramite il report TLS. Le moderne piattaforme DMARC nel 2026 includono sempre più spesso MTA-STS ospitato come funzionalità standard, semplificando il deployment della sicurezza del trasporto.

Che cos’è DANE e come si differenzia da MTA-STS?

Pubblicato con la RFC 7671, DANE (DNS-based Authentication of Named Entities) introduce un nuovo standard Internet per instaurare la comunicazione TLS tra client e server, senza dipendere dalle Certificate Authority (CA) fidate.

Il modello tradizionale delle CA per TLS permette a qualsiasi CA di emettere certificati per qualsiasi dominio. DANE opera diversamente affidandosi all’infrastruttura DNSSEC (Domain Name System Security Extensions) per vincolare un dominio a un certificato. DANE si serve dell’attuale protocollo DNSSEC per assicurarsi che i dati ricevuti siano autentici e non manomessi.

DANE introduce anche un nuovo tipo di record DNS chiamato TLSA che segnala al client che un server supporta TLS. Si consiglia di implementare sia MTA-STS sia DANE. DANE è un requisito di molti enti pubblici — per esempio, spesso le agenzie pubbliche dell’UE sono obbligate ad implementarlo.

DANE e MTA-STS sono efficaci solo se il mittente li supporta; poiché molti supportano solo uno dei due, implementarli entrambi migliora la sicurezza complessiva. Nel 2026, le organizzazioni spesso implementano prima MTA-STS per compatibilità più ampia e in seguito aggiungono DANE per una sicurezza avanzata quando richiesto.

A cosa serve la subdomain policy (tag sp) di DMARC e come va utilizzata?

La subdomain policy consente agli amministratori di dominio di proteggere i vari domini e sottodomini a seconda dello stadio in cui si trovano nel percorso DMARC. Per esempio, se tutti i servizi che inviano email per conto del tuo dominio principale sono configurati correttamente con SPF e DKIM, puoi proteggere il dominio principale con una policy DMARC p=reject lasciando i sottodomini su p=none, e viceversa.

Ancora, se hai un servizio di invio email che non è compatibile con DMARC (non supporta SPF o DKIM), potresti decidere di attribuirgli un sottodominio che avrà una policy DMARC diversa, senza impedirti di proteggere gli altri domini. In questo modo puoi suddividere il traffico tra vari sottodomini e proteggere ciascuno separatamente.