These settings are important to ensure that your email campaign is delivered. If you have any questions about this please contact us at

How to implement?

SPF record must be added to the DNS settings of each sending domain as TXT record type: Name/Host/Label: set it as a subdomain or to @ if you are not using a subdomain.

Record type: "TXT"

Value/text: "v=spf1 ~all"

It uses the TXT DNS record published on the Return-Path domain and relies on the receiving server to look up, parse, analyze and compare that TXT record with the IP address of the MTA that pushed the e-mail in question to the recipient's final. service. Recipients who verify SPF information in TXT records may reject messages from unauthorized sources before receiving the body of the message: "550 Message rejected because SPF verification failed"

To ensure that emails are delivered, it is important to set up SPF, DKIM and DMARC for each sending domain or subdomain. Below are the basic rules for setting up DKIM and DMARC:

DKIM record:

  • Record type: CNAME
  • Host name:
  • Content/value:

TXT record for DMARC:

  • Record type: TXT
  • Record name: _dmarc
  • Value: v=DMARC1; p=none; rua=mailto:youremail address (where you want to receive reports)
  • TTL: 3600

It is important to note that DMARC is required by Gmail and Yahoo because these major ISPs strengthen their email rules for all incoming messages."

The SPF record contains rules about which IP addresses are or are not allowed to send e-mail for a specific hostname (one specified in the Return-Path-header field). Each record begins with "v=spf1".

This is due to the fact that TXT records can be used to contain a variety of data and an SPF record must correctly identify itself as such to ensure that the SPF validation parser checks only relevant information.

You can check the SPF syntax and SPF specifications at


SPF Sender Policy Framework (SPF) is an attempt to control forged e-mail.

SPF is not directly about stopping spam and junk e-mail. It is about giving domain owners a way to tell which e-mail sources are legitimate for their domain and which are not. 

Email authentication (SPF, DKIM, DMARC)

E-mail authentication refers to a set of tools that enhance the legitimacy of an e-mail, allowing you to determine the source of each specific e-mail. 

This is used to deter spammers, fraudsters, phishers and other forms of e-mail abuse.

Mechanisms such as SPF, DKIM and DMARC are discussed in this article to ensure your email does get into the recipient's mailbox.


DKIM DomainKeys Identified Mail (DKIM).

This is an email authentication method designed to detect email spoofing.

Allows the recipient to verify that an e-mail claimed to come from a specific domain is indeed authorized by the owner of that domain.

DKIM allows a domain to associate its name with an e-mail message by adding a digital signature to it. Verification is performed using the signer's public key published in the DNS. A valid signature guarantees that some parts of the e-mail (possibly including attachments) have not been altered since the signature was applied. DKIM provides two separate operations, signing and verification.

Either can be handled by a mail transfer agent (MTA) module. DKIM keys are generated in pairs: private and public. DKIM relies on what is called "asymmetric cryptography" (also known as "public-key cryptography").

After a message is received and before that message is delivered to the destination, DKIM uses a "private key" to create a signature. This signature is added to the message.

When the message is delivered to the destination, the destination server asks the sender for a public key to verify that the signature is correct.

If the public key allows the destination server to decrypt the provided signature to the same value it computes as the signature, it can assume that the sender is indeed who it claims to be.

DKIM is assigned automatically, in some cases it must be placed on your server to prevent spoofing.


DMARC is built on top of two existing mechanisms,

Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). Unlike SPF and DKIM, DMARC is not designed to add legitimacy to e-mail, but to outright prevent potentially fraudulent e-mails from being accepted.

It ensures that legitimate email is properly authenticated to established DKIM and SPF standards, and that fraudulent activity that appears to originate from domains under the organization's control (active sending domains, non-sending domains and defensively registered domains) is blocked.

DMARC allows senders to instruct email providers on how to handle unauthenticated email through a published DMARC policy, eliminating guesswork on how to handle messages that fail DMARC authentication. Senders can: monitor all email to understand their brand's email authentication ecosystem and ensure that legitimate email is correctly authenticated without disrupting the delivery of failed messages, D

MARC instructs to quarantine messages that fail DMARC (e.g. move to spam folder) instructs to reject messages that fail DMARC (e.g. don't deliver the email at all) DMARC relies primarily on domain alignment and reporting functions.

It also uses the DNS system to publish policies, just as SPF and DKIM do. The alignment feature prevents spoofing of the "header from" address by: matching the "header from" domain name with the "envelope from" domain name used during an SPF check (matching From to Return-Path); matching the "header from" domain name with the "d= domain name" in the DKIM signature (matching From to DKIM d=) For more information about DMARC, go to NOTE: If you want to set up DMARC, make sure you have set up custom DKIM and SPF before making any changes.

A message fails DMARC if the message fails both SPF (or SPF alignment) and DKIM (or DKIM alignment).

It is recommended that DMARC be tested for some time with p=none policies before other policies are implemented, since p=none allows the sender to receive forensic and aggregate reports without the risk of having their email rejected or quarantined.