Enforce authentication with a DMARC policy

To add a DMARC policy to your domain, you must understand the follow concepts:

• Domain Name System and DNS records, TXT records in particular
• IP addresses

To convince you that you're interacting with a trusted source, unauthorized senders might impersonate a specific email address. This act of impersonation practice is known as email spoofing. The purpose of spoofing can include getting sensitive data, taking over other online accounts, or stealing funds.

A spoofed email includes a forged From address, but not the From the recipient sees in their inbox. Email messages have their metadata which includes two From addresses:

Spoofing works as part of a phishing attack. Phishing seeks to get recipients to open email messages with links to malicious web sites or open damaging attachments.

While you could consider spoofing and phishing as a recipient's problem, an attacker that uses your email domain can damage your email reputation.

Two other standards, DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF), authenticate email messages and senders, respectively. DKIM only validates the email address in the Envelope From.

To prevent email spoofing, DMARC policies determine what recipient email servers should do with email messages that pass and fail authentication checks.

The SPF authenticates that the email server that sent the message can send messages on behalf of the domain. When the receiving email server gets the message, it requests the SPF record from the sender's DNS server. If the IP address or IP address range matches the IP address of the sending email server, the receiving email server accepts the incoming email message.

The SPF sets an allowlist that identifies which email servers can send email messages on behalf of a given domain. To implement SPF, you add a TXT record to your DNS server for your domain. The TXT record specifies the IP addresses that can send email for the related domain.

To perform an SPF check, the following steps take place.

1. The receiving email server receives a message and checks the Envelope From (return-path).
2. The receiving server retrieves the SPF record from the DNS records for the domain in the return-path.
3. The receiving server checks the SPF record for all IP addresses approved to send email on behalf of the domain.
4. If the SPF check passes, the receiving server considers the message sent from an approved sending server and continues processing the message.
5. If the SPF check fails, the receiving server considers the message illegitimate. What happens after a failure depends on your DMARC policy.

To learn more about how SPF works, see Verify sending email servers with SPF.

DKIM authenticates the integrity an email message using public-key encryption. This standard ensures that nothing tampered with the message in transit.

1. The sending email server includes a signature in each email message's header. The signature includes an encrypted and hashed version of the email message header and body and instructions on how to decode the signature.
2. After receiving the email message, the receiving email server requests the DKIM record from the domain's DNS provider. This includes the public key to decrypt the signature data.
3. The receiving server then recreates the signature from the email message and compares it to the decrypted and decoded signature that got sent.
4. If the signatures match, the DKIM check passes and the email message gets accepted.
5. If the signatures don't match, the DKIM check fails. What happens after a failure depends on your DMARC policy.

To learn more about how DKIM works, see Verify senders with DKIM.

While DKIM authenticates the email message and SPF authenticates the sending email server, neither tells the receiving server how to act on the results of these checks. DMARC provides that function. It tells the receiving email server what to do with email messages that pass or fail authentication.

DMARC doesn't work as an independent authentication protocol but as a framework for handling SPF and DKIM failures and reporting those failures to domain owners.

• DMARC allows domain owners to specify what should happen if either or both SPF and DKIM checks fail.
  • Neither SPF nor DKIM provide this functionality on their own.
  • This means that without DMARC a sender can't determine what happens to a failed message.
• A sender receives no feedback about SPF and DKIM failures without DMARC, so senders have little chance to combat or even understand the delivery trends of their domain, often called reputation monitoring.
• SPF and DKIM are independent of each other, but neither provide thorough spoofing protection on their own.

DMARC builds upon SPF and DKIM. SPF and DKIM handle the domain-based message authentication part of DMARC.

DMARC adds reporting and conformance. Like SPF and DKIM, you implement DMARC through a TXT DNS resource record. Using this record, receiving email servers can fetch failure processing instructions from domain owners.

To check if an organization uses DMARC, see the DMARC.org FAQ entry.

To provide access to your DMARC policy, add it into the DNS registry of your domain as a TXT resource record. The policy follows a format of a series of semicolon-separated tags:

1
v=DMARC1;
2
p=(none|quarantine|reject);
3
rua=mailto:<email address>

The TXT record value must adhere to the following standards:

• It must follow RFC 1035 3.3.14 format for DNS records.
• It can't exceed 512 bytes.
• It must start with v=DMARC1;. This identifies the policy as using DMARC version 1.

You can write your DMARC policy yourself or use a DMARC policy generator.

A DMARC policy contains several semicolon-separated (;) tags. DMARC requires two tags: v (version) and p (policy).

The tag covers the policy applied to emails that fail the DMARC check.

The version, v=DMARC1, tells receiving servers that the DNS TXT record is a DMARC version 1 record.

The policy, p, can be one of three values, none, quarantine, or reject. Domain owners provide DMARC policies as instructions to a receiving email server on handling SPF and DKIM failures.

Where do the failure reports go? The address assigned to rua= tells receiving email servers where to deliver aggregate reports. The address assigned to ruf= tells receiving email servers where to send forensic reports.

1. Aggregate reports get sent daily by default. They don't include detailed information about individual failures.
2. Forensic reports send detailed information about individual failures at the time of failure. The email address assigned to ruf must also use the domain on which the DMARC record exists.

The request format, rf=afrf, tells receiving servers how to format reports for the domain owner. Authentication Failure Reporting Format, afrf, is the default and is an extension of Abuse Reporting Format.

The fo tag tells receiving servers what type of failures to report. There are four possible values for this tag.

1. fo=0: Send a report if both SPF and DKIM checks don't pass. This is the default value.
2. fo=1: Send a report if either SPF or DKIM checks don't pass.
3. fo=d: Send a report only if the DKIM check doesn't pass.
4. fo=s: Send a report only if the SPF check doesn't pass.

The ri tag sets the interval in seconds at which a domain owner wishes to receive aggregate reports. This value defaults to 86400 seconds or 24 hours.

Two tags manage SPF, aspf, and DKIM, adkim, alignment. These values determine how exact the domains in the From and the return-path email addresses must match for the check to pass. This tag accepts two values: r (relaxed) and s (strict).

• Strict: Only return-path domains that match the domain set in the SPF or DKIM record exactly pass the check.
• Relaxed: Any return-path domain that matches the parent domain set in the SPF or DKIM record pass the check. This allows CNAME addresses to pass a check.

The following table illustrates how alignment works:

To specify different policies for subdomains, use the sp tag. Like the policy tag, p, the possible values for the sp tag are none, quarantine, and reject.

For example: You can apply a reject policy to your root domain and a quarantine policy for all its subdomains.

The percent tag, pct, specifies how many failing email messages follow your DMARC policy. The possible values are 1 through 100.

For example: If you set your policy to quarantine and your percent to 50, half of all failing email messages get quarantined.

You can adjust this tag value as you learn more about DMARC failures on your domain.

The reporting function of DMARC comes from two reports: an aggregation report and a forensics report.

Every 24 hours, inbox providers generate DMARC aggregate reports as compressed XML documents. It then attaches the reports to an email message as a ZIP archive. The email address you choose to receive reports must accept ZIP attachments. The files use the following filename format:

The following sample DMARC report includes one record with the results for two email messages. The SPF and DKIM auth_results report tag produce raw results, ignoring the s= alignment.

1
<?xml version="1.0" encoding="UTF-8" ?>
2
<feedback>
3
  <report_metadata>
4
    <org_name>google.com</org_name>
5
    <email>noreply-dmarc-support@google.com</email>
6
    <extra_contact_info>http://google.com/dmarc/support</extra_contact_info>
7
    <report_id>9391651994964116463</report_id>
8
    <date_range>
9
      <begin>1335571200</begin>
10
      <end>1335657599</end>
11
    </date_range>
12
  </report_metadata>
13
  <policy_published>
14
    <domain>example.com</domain>
15
    <adkim>r</adkim>
16
    <aspf>r</aspf>
17
    <p>none</p>
18
    <sp>none</sp>
19
    <pct>100</pct>
20
  </policy_published>
21
  <record>
22
    <row>
23
      <source_ip>203.0.113.94</source_ip>
24
      <count>2</count>
25
      <policy_evaluated>
26
        <disposition>none</disposition>
27
        <dkim>fail</dkim>
28
        <spf>pass</spf>
29
      </policy_evaluated>
30
    </row>
31
    <identifiers>
32
      <header_from>example.com</header_from>
33
    </identifiers>
34
    <auth_results>
35
      <dkim>
36
        <domain>example.com</domain>
37
        <result>fail</result>
38
        <human_result></human_result>
39
      </dkim>
40
      <dkim>
41
        <domain>sender.net</domain>
42
        <result>pass</result>
43
        <human_result></human_result>
44
      </dkim>
45
      <spf>
46
        <domain>example.com</domain>
47
        <result>pass</result>
48
      </spf>
49
    </auth_results>
50
  </record>
51
</feedback>

The XML file contains three main tags inside a feedback tag: record_metadata, policy_published, and record. The record tag repeats for each email source IP address.

The record_metadata tag contains the following tags:

The policy_published tag contains the following tags:

Each record tag contains the following tags:

When sending email with a service provider such as Twilio SendGrid, you must authenticate a domain or verify a Single Sender.

Twilio recommends authenticating a domain that you do control. The Twilio SendGrid domain authentication process provides CNAME records that you place on your own domain to approve the Twilio SendGrid IP addresses. To protect your domain's reputation, Twilio manages your SPF and DKIM records.

Many inbox providers implement DMARC, including:

• AOL
• Gmail
• Microsoft (Hotmail, MSN)
• Outlook
• Yahoo

Providers with DMARC policies might reject email with messages like:

521 5.2.1 : (DMARC) This message failed DMARC Evaluation and is being refused due to provided DMARC Policy

If bounce with one of these failure messages appears, Twilio SendGrid discarded and tracked it as a Block. Adjust your From address field settings, and then try resending.

Gaining insight from these XML documents can be difficult.

To collect the reports and present not the data but actionable insights, Twilio recommends using a DMARC report monitoring service.

Twilio SendGrid partners with Valimail. To leverage their DMARC monitoring and inbox provider alignment support, perform the following tasks:

1. Set up an account through Valimail.
2. Add rua=mailto:dmarc_agg@vali.email in your DMARC record.

• Valimail Align
• How to Implement DMARC
• Sender Identity
• Domain Authentication
• Single Sender Verification
• DMARC.org