Stillwater Cyber Compliance

Fake Email and Deepfakes

SPF, DKIM, and DMARC: Essential Explanations

Everyone wants a magic bullet to mitigate the risk of email spoofing, as well as advice from security professionals on how to configure systems to prevent their domains being used as the source of fake emails.

Security professionals know you can never remove all risk,  but you can reduce the likelihood of your domains being used to support fake emails.  The tools have been around since early 2000s like Sender Policy Framework (SPF),  DomainKeys Identified Mail (DKIM) and domain-based message authentication, reporting and conformance (DMARC) records in their DNS configuration.

However only 20% of companies use DMARC, SPF, and DKIM, global anti-domain-spoofing standards that can significantly reduce phishing attacks. Unfortunately when they are configured, they are not always enabled correctly, allowing 81% of phishing attacks to continue to sail right through to the end-user.

I want you to have a thorough understanding of them. The explanations are technical, but these are three fundamental concepts to understand about email authentication.

I’ll provide you with a brief and insightful look at each of these protocols, then you’ll be able to start tossing these acronyms around like the security pros.

What is email authorization?

Email authorization helps to improve the delivery and credibility of your marketing emails by implementing protocols that verify your domain as the sender of your messages.  

SPF (Sender Policy Framework) is a DNS text entry which shows a list of servers that should be considered allowed to send mail for a specific domain. Incidentally the fact that SPF is a DNS entry can also considered a way to enforce the fact that the list is authoritative for the domain, since the owners/administrators are the only people allowed to add/change that main domain zone.

SPF, Sender Policy Framework, is a way for recipients to confirm the identity of the sender of an incoming email.

  1. The sender adds a record to the DNS settings.

1.    The record is for the domain used in their FROM: address (e.g. if I send from, add the record to This record includes all IP addresses (mail servers) that are authorized to send mail on behalf of this domain. A typical SPF record will look something like this:
v=spf1 ip4: ip4: ip4: ~all

  1.  The receiving server checks the DNS records.

1.    When the mail is sent, the receiving server checks the DNS records for the domain in the FROM: field. If the IP address is listed in that record (as seen above), the message passes SPF.

  1. If SPF exists, but the IP address isn’t in the record, it’s a hard fail.

1.    If the SPF record exists, but the IP address of the sending mail server isn’t in the record, it’s considered a “hard-fail.” This can often cause mail to be rejected or routed to the spam folder.

  1. If no SPF record exists, it’s a soft fail.

1.    If no SPF record exists at all, this is considered a “soft-fail.” These are most likely to cause messages to be routed to spam but can lead to a message being rejected as well.

What is email authentication?

DKIM (DomainKeys Identified Mail) should be instead considered a method to verify the messages authentication, meaning that they weren’t changed from the moment the message left the initial mail server. This layer of authentication is achieved by an implementation of the standard public/private key signing process. Once again the owners of the domain add a DNS entry with the public DKIM key which will be used by receivers to verify that the message DKIM signature is correct, while on the sender side the server will sign the entitled mail messages with the corresponding private key.

How does DKIM work?

  1. When sending an outgoing message, the last server within the domain infrastructure checks against its internal settings if the domain used in the “From:” header is included in its “signing table”. If not the process stops here
  2. a new header, called “DKIM-Signature”, is added to the mail message by using the private part of the key on the message content
  3. from here on the message main content cannot be modified otherwise the DKIM header won’t match anymore
  4. upon reception the receiving server will make a TXT DNS query to retrieve the key used in the DKIM-Signature field
  5. the DKIM header check result can be then used when deciding if a message is fraudulent or trustworthy


DMARC (Domain-based Message Authentication, Reporting and Conformance) empowers SPF and DKIM by stating a clear policy which should be used about both the aforementioned tools and allows to set an address which can be used to send reports about the mail messages statistics gathered by receivers against the specific domain.

Broadly speaking DMARC works as follows:

  • Upon receipt the receiving mail server checks if there is any existing DMARC policy published in the domain used by the SPF and/or DKIM checks.
  • If one or both of the SPF and DKIM checks succeed while still being aligned with the policy set by DMARC, then the check is considered successful, otherwise it is set as failed.
  • If the check fails, different actions are taken based on the action published by the DMARC policy.


I would start your DMARC implementation with a simple monitoring policy for your domain which requests that DMARC capable mail servers send you statistics about emails they see using your domain. You can do this even before you’ve implemented SPF or DKIM in your messaging infrastructure, though until it is in place you won’t be able to move beyond this step.

As you introduce SPF and DKIM, reports will provide the number and IP addresses of emails that pass these checks, and those that don’t. You can then see how much of your legitimate traffic is passing SPF and DKIM checks, and troubleshoot any problems with your SPF or DKIM configuration.

You will also begin to see how many fraudulent emails are being sent, and from where. At this point you should put in place a capability to review reports from recipient mail servers sent in accordance with DMARC configuration to identify malicious activity.

An example of such a DMARC record is v=DMARC1; pct=50; p=none; sp=quarantine;;


  • v=DMARC1 defines the version of DMARC being used
  • pct=50 specifies the percentage of emails subjected to filtering
  • p=none specifies the policy for your company domain
  • sp=quarantine specifies the policy for all company subdomains
  • states the email address to which forensic reports should be sent
  • states the email address to which aggregate reports should be sent.

Questions about DMARC

To ease implementation and analysis consider using a service like, which can also be used to view your DMARC records.

 Can you use DMARC with Office 365?

I would read over  the Microsoft publication

 Can you Redirecting subdomains SPF records to save time?

An individual SPF record must be set for each domain and subdomain. However, to avoid creating a unique SPF record for each subdomain, you can redirect them to your top level domain. For example, you can set all subdomain records to be v=spf1 This configuration will mean that all subdomains will use the SPF record of their parent domain, This is effective if, for example, all emails from subdomains pass through a centralized email relay.

Can you use wildcard SPF records to protect non-existent domains?

A wildcard SPF record (*.) is required for every domain and subdomain to prevent adversaries sending emails claiming to be from a non-existent subdomain. Examples of wildcard SPF records follow. TXT “v=spf1 –all”

*. TXT “v=spf1 –all”

*._domainkey. TXT “v=DKIM1; p=”_dmarc. TXT “v=DMARC1; p=reject; ruf=mailto:authfail@; rua=mailto:aggrep@”

Even though this domain doesn’t send email, the SPF and DKIM records are needed to prevent adversaries sending emails pretending to be you and the DMARC record is needed so you are notified when this happens.

 What about CNAME records?

Canonical Name (CNAME) records are a common DNS technique used to enable transparent redirection to an alternate domain name. They are frequently used by companies to redirect requests for services to a third party service provider (e.g. a public cloud). While this is an effective technique, companies need to be aware that a CNAME record effectively delegates all DNS calls for the target domain to the domain specified in the answer section.

For example, if you have CNAME then requests for the SPF, DKIM and DMARC records for will be answered as if directed to  Hence, if a CNAME record is used in your DNS record to redirect requests to an alternate domain, then it will not be possible for you to specify SPF, DKIM and DMARC records. This is a risk that needs to be accepted when deciding to delegate DNS records in this manner. Appropriate SPF, DKIM and DMARC records can be discussed with your service provider, and can be specified in contracts when engaging with such services.

Sending DMARC reports to a different domain

If your domain is and you want to send your reports to, then the recipient domain ( needs to have a TXT DNS record at which has content v=DMARC1.

If you are sending all your reports to the same domain, you may want to implement a wildcard DMARC record so you can receive reports from anyone who wants to send them to you. A wildcard record would be * which specifies v=DMARC1. However, doing this allows attacks where adversaries can send huge amounts of DMARC reports in an attempt to cripple your infrastructure. 


The technical explanation can be a little overwhelming and implementation scary if mail flow is damaged.  But if you can break it down to these points and use tools to monitor reports.  It is not that hard

● Implementing DMARC is all about locating and protecting your valid sending sources

● How can this be translated into understandable situations?

● Source investigation process – mapped to real-life scenarios