DMARC: How to Prevent Email Spoofing

Modern email authentication uses a combination of three methods: SPF, DKIM, and DMARC. These methods help ensure that a message came from a sender shown in the From header.

By deploying DMARC, email senders can prevent spoofed spam and phishing emails from reaching their email subscribers and customers, protecting their brand and the subscribers’ personal data.

This post explains the basics of SPF, DKIM, and DMARC, and tells how to deploy DMARC properly and read DMARC reports.

Email spoofing is sending an email with the falsified email address. The sender forges an email header to make a recipient think that the letter came from a different source than it actually did, and the goal is for a recipient either to open an email or to re-send it to someone else.

The common reasons for spoofing are:

• Hiding the real name of a sender;
• Avoiding blacklisting;
• Identity theft;
• Impersonating someone who the recipient knows;
• Impersonating a business that the recipient works with.

In this day and age, spoofing is possible because SMTP (Simple Mail Transfer Protocol) does not provide email authentication. But there are certain protocols to secure emails from malicious activity.

So, how to prevent email from spoofing?

To protect oneself, the incoming messages should be properly authenticated. Three globally adopted protocols help accomplish this goal: SPF, DKIM, and DMARC.

What is SPF Record?

SPF stands for Sender Policy Framework – a protocol that identifies servers that are allowed to send emails on behalf of a certain domain name. SPF record comes in a form of TXT record in the DNS records with the list of email addresses that have permission to send messages from your domain.

SPF was the first method of email authentication widely adopted by email senders. Most email receivers still want you to have it deployed on your domain to deliver your messages. For example, Gmail and G Suite will throttle emails sent from a domain that doesn’t have a valid SPF record.

How SPF record works

SPF record helps the server answer two main questions:

• Who sent the email?
• Is he authorized to send emails from this domain?

If the message is sent from an unauthorized email, the recipient’s server may mark it as spam.

SPF record works by checking for a specially formatted TXT record in DNS of the domain of the Mail FROM header (also called Return-Path, Envelope From or Return email address) in the SMTP transaction. The SPF record tells which servers are authorized to send mail from that domain by using mechanisms to specify authorized IP addresses and hostnames, or even including the SPF records of other domains.

How to Create an SPF Record

To create an SPF record follow these steps:

1. Make a list of all the servers that are used to send emails on behalf of your domain.

   Include all possible servers that might be involved in managing the emailing process from your brand, including an office server, your company’s ISP, etc.

2. Make a list of all the domains your emails may be sent from.

   If your company has more than one domain, add all of them to increase your anti-spoofing protection.

3. Create an SPF record.

   An SPF record starts with v=spf1. After that, mechanisms are used to specify which mail servers are allowed (or not allowed) to send emails on behalf of that domain or subdomain. Note, that a domain or subdomain can have only one SPF record, but each subdomain can have its own SPF record. Scroll down to see an example of an SPF record.

4. Publish your SPF to the DNS record.

   To accomplish this step you should contact your DNS service administrators. Some hosting providers make this procedure pretty simple, but if you have any doubts we recommend contacting IT support.

5. Test the SPF record.

10 DNS Lookup Limit

Some mechanisms use additional DNS lookups to work. SPF has a maximum DNS lookup limit of 10, including any included records. An SPF record that requires more than 10 DNS lookups to resolve is invalid!

You can test your SPF record in GlockApps. Copy-paste the domain with the SPF record in the SPF Validator and click “Check SPF”.

To comply with this limit, send emails from different subdomains. Each subdomain can have its own SPF record and its own set of limits for that record. For example, you could send email newsletters from newsletter.example.com, and transaction emails from account.example.com.

SPF’s Mechanisms, Qualifiers and Modifiers

Below is the list of SPF mechanisms and their descriptions:

ip4: describes an ipv4 address or CIDR block of addresses.

ip6: describes an ipv6 address or block of addresses.

mx: describes the servers listed in the mx record of the domain, counts against the 10 DNS lookup limit.

mx – the servers listed in the mx records of its own domain.

mx:example.com – the servers listed in the mx records of example.com.

a: describes the servers listed in the A and/or AAAA records of the domain, counts against the 10 DNS lookup limit.

a – the IP addresses listed in the domains’ own A/AAAA records.

a:example.com – the IP addresses listed in the A/AAA records of example.com.

include: includes the SPF record from the domain after the colon (it does not include the all modifier, if any). Counts against the 10 DNS lookup limit.

redirect: stops processing the SPF record, and continues at the specified domain’s SPF record (including the all modifier!). Counts against the 10 DNS lookup limit.

exists: used to construct an arbitrary domain name that is used for a DNS A record query. It allows for complicated schemes involving arbitrary parts of the mail envelope to specify what is permitted. Counts against the 10 DNS lookup limit.

Mechanisms in the SPF record are preceded by qualifiers. Possible qualifiers are:

+ (pass): a “pass” result means the client is authorized to inject mail with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. Further policy checks can now proceed with confidence in the legitimate use of the identity.

? (neutral): a “neutral” result indicates that although a policy for the identity was discovered, there is no definite assertion (positive or negative) about the client. A “neutral” result must be treated exactly like the “none” result. The difference exists only for informational purposes. With a “none” result, the SPF verifier has no information at all about the authorization or lack thereof of the client to use the checked identity or identities. The check_host() function completed without errors but was not able to reach any conclusion.

~ (softfail): a “softfail” result has to be treated as somewhere between “fail” and “neutral”/”none”. The domain manager believes the host is not authorized but is not willing to make a strong policy statement. The email receiver should not reject the message based solely on this result but may subject the message to closer scrutiny than normal.

– (fail): a “fail” result is an explicit statement that the client is not authorized to use the domain in the given identity. Disposition of messages with the SPF fail is a matter of local policy.

SPF records (except those that are designed to be included in other SPF records) end with an all modifier. The all modifier consists of the word all preceded by a qualifier. The all modifier states how emails that do not match any of the listed mechanisms should be treated.

SPF’s Weak Side

It’s a common misconception that SPF prevents email spoofing. It doesn’t stop it, but it makes email spoofing a little bit difficult for an attacker.

As we told above, SPF checks for an SPF record at the domain in the Mail FROM header in the SMTP transaction (also known as the Return-Path or Envelope From), not in the message From header that the recipient sees in their email client.

This means that an attacker can use SMTP headers to tell the target’s mail server to check a domain that the attacker controls, which contains an authorizing mechanism for the mail server the attacker is using while spoofing a completely different domain for the recipient to see in the message From header field.

A domain mismatch occurs legitimately when a mailbox rule forwards a message from another domain. The email “From” domain will stay the same, but the SMTP Mail FROM header will contain the domain of the forwarding mail server. Hence, SPF evaluation fails.

Once you know exactly which email sources legitimately send on behalf of your domain (DMARC reports will tell you), update the SPF record for your domain, and change the ?all modifier to -all.

Examples of SPF Record

SPF record for new domains:

v=spf1 mx ?all

This record authorized any servers listed in the domain’s MX record while treating all other servers as neutral. This is a good temporary SPF record for new domains that do not have an SPF record yet.

Office 365:

v=spf1 include:spf.protection.outlook.com ?all –

G Suite:

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

SPF record for domains that do not send emails (e.g. parked domains):

v=spf1 -all

This record explicitly states that no mail servers are authorized to send emails on behalf of this domain. This must be added to all domains that do not send emails, inducing parked domains.

Read more:

How to Deploy SPF Email Authentication
How to Optimize Your SPF Record

What is DKIM?

DKIM stands for DomainKeys Identified Mail. It is an email authentication method developed to detect forged email header fields and content. DKIM allows the receiver to check whether or not email headers and content have been altered in transit. DKIM and SPF provide different methods of email legitimacy.

DKIM provides a keypair that consists of a public key and a private key. The private key goes to your server and the public key – to your DNS.

How does DKIM Work?

A DKIM-enabled email server signs an email message on its way out, using a private key, which is a part of a generated keypair.

When the message arrives, the receiving server checks if a DKIM-Signature field exists in the header, and if it does, the server uses the DKIM public key in the DNS to validate the signature.

Depending on the result of the DKIM signature check on the receiving server, the email passes or doesn’t pass DKIM authentication. The DKIM authentication result is then used for DMARC authentication.

Tags in DKIM DNS Record

For a better understanding of tags, let’s look at a DKIM-signature header field:

v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=tiadfhs7i3i3dkzhbjmofp6nm32djwj2;
d=glocksoft.com; t=1568985733; h=Content-Type:MIME-Version:Date:Subject:From:Reply-To:
Message-ID:List-Unsubscribe:List-ID:To; bh=+hSM8asLAUZKQQF1ecbzNmIunG0V9QpwSswOeYayGKc=;
b=QW93Yb1i9A+oohrGAAApAEZt6jF4JxvwKC2ZGvNIFYtTzWJ6utmF5bADTE2QdDgY
AUW5ohGY01Tx1tBOFf6JEvh2k7xmvrMverarPQIhdmSs4dY9s8MZj9EnW/FDTgOJ4sL
ri6Oa/JUXJb5SCk+iI2b9tZm1IErq3h15jtqBFwg=

The tags that are required to be in a DKIM-signature are:

v: signature version
a: signing algorithm (rsa-sha256 should be used)
d: the domain where the public key can be found
s: the selector pointing to the public key at the domain (an arbitrary string)
h: a colon-separated list of header fields that have been signed
bh: the base64-encoded signature hash of the message body
b: the base64-encoded signature hash of the headers listed in the h tag

Optional tags are:

c: canonicalization algorithm(s) for header and body which define(s) if/how the receiving mail server should normalize the message to account for slight variations in whitespace and line breaks that could otherwise invalidate the signature. Relaxed mode is strongly recommended for the header and body canonicalization (i.e. c=relaxed/relaxed).

q: default query method
t: signature timestamp in UNIX timestamp format
x: signature expiration timestamp in UNIX timestamp format
l: number of characters from the beginning of the body to use when calculating the body signature (not recommended because someone could append malicious content)
i: identity/user-agent of the signer

Creating a DKIM Record

Just like SPF, DKIM records are TXT records installed in the DNS record.

Follow these steps to create a DNS record:

1. Go through all the domains you’re sending emails from.

   Whether it’s a domain you’re using to send a corporate email, marketing campaigns or customer service messages – all of these domains should be protected by DKIM.

2. Install DKIM package to your server.

   All of your outgoing emails must have a DKIM signature; therefore, DKIM package has to be installed on the server. If you don’t know whether DKIM software is available at your platform, go to dkim.org and check. If you use ESP – contact them to help you install the package.

3. Generate a public and private key.

   Use a tool of your choosing to generate keypair by entering the domain name ‘From:’ and the selector (the name of your key). There are plenty of free DKIM wizard tools available online.

Publishing a DKIM Record

fter you have created DKIM TXT you must:

1. Add public key to the DNS TXT record.

It can be done in the interface of your ESP, although you may have to contact your system administrator for further instructions.
DKIM public key records in a domain’s DNS are formatted as:

v=DKIM1; k=rsa; p=;

Lines in DNS TXT records are limited to 256 characters. If the record is longer, it must be split into separate lines in the same record to be valid.

Here are the tags that can appear in a DKIM DNS record:

Required tags:

p: base64 encoded public key (keys must be at least 1024 bytes long. 2048 bit length is strongly recommended)

Recommended tags:

v: version (must be “DKIM1”)

k: a list of mechanisms that can be used to decode a DKIM signature (rsa by default)

Optional tags:

g: granularity

h: a colon-separated list of hash algorithms that might be used to produce a digest of message data

n: readable notes for administrators reviewing DNS records

s: a list of service types to which this selector may apply

q: a list of query methods

l: body length limits

t: a list of flags to modify the interpretation of the selector

2. Store the private key.

Your DKIM package should specify where exactly the private key should be stored.

3. Make sure your DKIM is working right.

Follow instructions of your server, and, if needed, contact your server support team.

DKIM Key Rotation

The private key of a DKIM keypair may be stolen if an attacker compromises the system where it is stored. Therefore, it is recommended to change DKIM keys once per month. This practice is known as key rotation.

If you are using an email service provider or delivery service, you don’t have to do anything as DKIM key rotation is done automatically for you.

Manual DKIM key rotation is necessary only if you run your own email delivery service in-house.

You should create two key pairs and store the public keys under two different selectors, for example:

s1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=<public key 1>;"
s2._domainkey.example.com TXT "v=DKIM1; k=rsa; p=<public key 2>;"

Start by signing your outgoing emails using the s1 selector. When it is time to rotate the keys, sign outgoing emails using the s2 selector. After a week of not using the key at the s1 selector, replace the key at the s1 selector.

When it is time to rotate keys again, start using the s1 selector exclusively, wait a week, then replace the key at the s2 selector with a new key, so it will be ready for the next rotation.

It is important to wait a week before replacing the key (unless it is known to be compromised), as some receiving mail servers will cache the public key at a given selector for up to a week.

Using this rotation scheme, you’ll ensure that your emails are always signed with a valid, secure key.

DKIM’s Weak Side

Without DMARC, the domain in the d= tag in a DKIM signature in the header is not required to match the same domain that the user sees in the message From header field.

An attacker can place a valid DKIM signature header in an email with a d= value containing a domain the attacker controls, allowing DKIM to pass while still forging the From email address to the user.

What is DMARC?

DMARC (Domain-Based Message Authentication, Reporting, and Conformance) is a special protocol that reassures that an email was sent from a specific sender. It eliminates the possibility of phishing, spoofing and other malicious activity. DMARC also boosts the delivery rate by controlling the delivery process and making sure that an email will get straight to the recipient’s inbox, not the spam folder.

DMARC is built on the two widely used protocols SPF and DKIM.

How does DMARC Work

In a nutshell, DMARC makes it harder for an email to pass an authentication process. Even if the message passes SPF and DKIM, it can fail DMARC. How does it work?

In SPF the domain of the envelope’s Mail FROM and the domain of the header ‘From’ should be the same, or, in other words – aligned.

SPF pass: the mail server’s IP address is listed in the SPF record of the domain in the SMTP envelope’s Mail FROM header field.

SPF in alignment: the domain in the SMTP envelope’s Mail FROM header field aligns with the base domain in the message’s From header.

In DKIM the header ‘From’ address and the DKIM signature d=field should be aligned.

DKIM pass: the signature in the DKIM header is validated using a public key published as a DNS record of the domain name specified in the signature.

DKIM in alignment: the signing domain aligns with the base domain in the message From header field.

DMARC, in its turn, creates a so-called ‘Identifier Alignment’ – it takes results of SPF and DKIM alignments and connects them to the header ‘From’ field. In this way, it ensures that SPF and DKIM authentication mechanisms authenticate against the same domain that the end-user sees in the From header field. A message passes a DMARC check by passing DKIM or SPF, as long as the related indicators are in alignment with the message ‘From’ email address.

After an email passes these procedures, it means that the message was really sent from the email address visible to the receiver.

Note that DKIM alignment is more important than SPF alignment because only DKIM remains aligned when a message is forwarded.

DMARC Policy

DMARC requires email domain owners to add a policy (p=) tag in their DMARC record. This policy tells email receivers how they should treat an email that appears to come from the domain in the From header, but does not pass DMARC alignment.

There are three DMARC policies:

• none: no action will be taken regarding the delivery of messages. This policy is used for monitoring and collecting data about email authentication of the messages sent from a domain.
• quarantine: an email that fails the DMARC check will be treated by email receivers as suspicious. Depending on the email receiver, This can mean “send to spam folder”, “subject to thorough filtering”, and/or “flag as suspicious”.
• reject: an email that fails the DMARC check will be rejected during the SMTP transaction.

It is recommended to start with the “none” policy to collect data about email sources sending from the domain.

You can use the percent (pct) option to specify the percentage of suspicious emails (ones that fail the DMARC check) to have the DMARC policy applied. The default value is 100% (all suspicious messages). For example, p=quarantine pct=10 means that 10% of suspicious messages must be quarantined.

Increase the percentage over time as you refine your DMARC policy. Below is an example of how to use the p and pct options to gradually strengthen your DMARC policy:

Day 1: p=none pct=100
Day 20: p=quarantine pct=1
Day 23: p=quarantine pct=5
Day 26: p=quarantine pct=10
Day 30: p=quarantine pct=25
Day 35: p=quarantine pct=50
Day 50: p=quarantine pct=100
Day 60: p=reject pct=1
Day 65: p=reject pct=5
Day 70: p=reject pct=10
Day 75: p=reject pct=25
Day 80: p=reject pct=50
Day 100: p=reject pct=100

DMARC Record

Just like SPF and DKIM records, DMARC record is a specially formatted TXT string that is added to the domain. It is the implementation of the domain’s owner’s policy.

A DMARC record must be published in DNS by a domain owner, and email receivers must honor this record, including its policy, and send back DMARC reports if requested by the domain owner.

DMARC Report

Domain owners are required to set the rua and ruf tags in their DMARC record where they indicate the email addresses to send DMARC reports to. Email receivers that honor DMARC will send the reports to those email addresses.

DMARC reports give very useful information for monitoring and troubleshooting message alignment and identifying malicious sources sending on behalf of a domain.

There are two types of reports.

• Aggregate reports are compressed XML files which contain the number of messages sent from an IP address, and the SPF and DKIM status. These reports are sent regardless of success or failure so that domain owners have a picture of email authentication of all the messages that appear to be sent from the domain.

Aggregate reports in GlockApps DMARC Analytics

• Forensic reports are emails with the messages that failed the DMARC check attached. These reports can be very useful for identifying messages that failed DMARC. However, most email receivers do not send forensic reports, or may only provide the message headers for privacy reasons.

Forensic reports in GlockApps DMARC Analytics

You can use DMARC Analytics for free with 10,000 messages every month in your account. You will get visibility about your sending sources, SPF, DKIM, and DMARC evaluations and will be able to identify and block any suspicious mail streams coming from your domain.

Start Using DMARC

Learn More:

Email Spoofing Attacks in 2023
DMARC Monitoring and Reporting: Step-by-Step Guide
Authenticate Emails with DMARC for Better Deliverability