What are DMARC, SPF and DKIM?

Much of the interpersonal communication on the internet still depends on one of the oldest internet services: electronic mail. Social networking and other mobile services have not changed this. More than ever, those wishing to do harm on the internet have a tremendous financial incentive to compromise user accounts, enabling theft of passwords, bank accounts, credit cards and other security violations. The original electronic mail protocols never envisioned the risks to consumers in simple email spoofing. In some cases, the simple insertion of a logo of a famous brand is enough to give email legitimacy with many users.

Even sophisticated users can be fooled by fake messages. And large providers of mail services have to make very difficult choices about which messages to deliver and which ones they should not. DMARC is a technical specification, using the DNS and mail servers, to attempt to deal with some of these issues. The goal is to help email senders and receivers work to reduce the number of phishing attacks and other malicious email-borne activities.

There are three standards that make up the email authentication technology:

  • DMARC – Domain-based Message Authentication, Reporting and Conformance is a technology that uses the resources of DNS and email servers to help avoid email abuse—specifically, phishing. It is layered over two technologies (SPF and DKIM) that allow for the specification of policies for incoming email. Publishing a DMARC record is one of the Requirements; 
  • SPF – Sender Policy Framework is a technology that allows an administrator to publish information about legitimate sending hosts in a specially formatted DNS resource record; and
  • DKIM – DomainKeys Identified Mail is a technology that allows a mail receiver to check that incoming mail from a domain is authorized by that domain’s administrators and that the email has not been changed as it has gone through the network.

fTLD recommends that both SPF and DKIM be used with DMARC. However, the requirement only specifies that an SPF record must be created. In practice, email authentication is more effective in the presence of both SPF and DKIM records as email delivery rates will be increased.

What is the fTLD Domain Security Requirement for Email Authentication?

Registrants that have met requirements #1 and #2, and therefore appear in the .BANK or .INSURANCE zone, must publish a valid Domain-based Message Authentication, Reporting and Conformance (DMARC) record whether or no the domain is used to send email.

For a domain used to send email: Registrants must publish a DMARC record with a "reject" mail receiver policy (p=reject), except during the implementation phase of email set up as described below*. In addition, Registrants must publish a Sender Policy Framework (SPF) record. While publishing a DomainKeys Identified Mail (DKIM) record is not required, publishing both SPF and DKIM records creates additional security for your email channel.

It is recommended that DMARC records specify strict identifier alignment for both SPF and DKIM (if applicable) via the adkim and aspf tags. Also, for DMARC records published at an organizational domain level to set an appropriate "sp: tag" for subdomains.

When used to protect non-email sending domains, Registrants are required to publish a DMARC reject requested mail receiver policy.

The goal of this requirement is to provide an increased level of trust for email from an fTLD Domain. This is done by using an internet-standard approach to email authentication. This is a crucial requirement for ensuring that the electronic mail channel for an fTLD Domain is protected against the delivery of invalid or spoofed email purporting to be from an fTLD Domain.

What is Email Authentication and Why is it Important?

Email authentication allows the receiver of an email to make judgements about the sender of that email. In addition, the sender can develop and publish policy for email authentication. If a receiver can establish authentication of the source of email, then one of the most difficult problems for email can be avoided— spoofing also known as phishing. Spoofing is the ability of someone to pretend to be another organization and attempt to lure an email receiver into using a rogue website instead of an authentic website or into providing confidential information in order to compromise sensitive user information. For organizations using an fTLD Domain, email authentication is an essential part of establishing trust in email coming from their organization. Email authentication assists in the prevention of phishing attacks and also plays a role in emerging reputation and accreditation systems that are another part of establishing trust in email as a vehicle for communications between financial services organizations and their customers. There are two basic types of email authentication: internet Protocol-based approaches and cryptographic approaches. The internet Protocol approach, SPF, requires publishing information about legitimate email servers in the DNS for each domain being used. The other approach, cryptographic, attaches a signature to each message in a way that is difficult to forge, proving that the message came from the indicated sending domain. The industry standard for the cryptographic authentication is DKIM. Today, companies are moving toward adoption of SPF, DKIM, or both. Major email providers such as Microsoft, Yahoo! and Gmail are using both SPF and DKIM to authenticate email senders. DMARC is a tool that uses SPF or DKIM to make decisions about incoming mail based on a published policy.

Understanding Email Authentication Protocols

The email authentication protocols are complex. While this section provides a basic overview and some examples, there are resources available to learn more about SPF, DKIM and DMARC. This section provides links to some of the available sources of information on the three protocols.

Example: Building a SPF Policy

Registrants are reminded that the development of DMARC, SPF and DKIM has been very dynamic. The online resources in the previous section should be considered authoritative. However, in this section, fTLD provides an example of what is needed to build a SPF policy record to meet the requirement. Registrants in an fTLD Domain zone are required to have a SPF or a DKIM record. Similar to the DNSSEC resource records noted earlier in this guide, a SPF record is a resource record that identifies which mail servers are permitted to send email on behalf of your domain.

The idea behind a SPF record is to prevent spammers from sending messages with forged “From” addresses at your domain. This is especially important in the case of an fTLD Domain where the goal is to establish high levels of trust between institutions and their customers. Email service providers (e.g., Google, Microsoft, Yahoo!), on behalf of their customers, refer to the SPF record to determine whether a message purporting to be from your domain comes from an authorized mail server and then deliver it or not.

For example, suppose that your domain example.bank uses your internal mail server. You create an SPF record that identifies your internal mail server (suppose it is mail.example.bank) as the authorized mail servers for your domain. When a recipient’s mail server receives a message from customerservice@ example.bank, it can check the SPF record for example.bank to determine whether it is a valid message. If the message comes from a server other than your internal mail servers listed in the SPF record, the recipient’s mail server can reject it as spam. It’s perfectly possible to have an SPF record that authorizes more than one domain as the legitimate server for your outbound email.

If your domain does not have an SPF record, some recipient domains may reject messages from your users because they cannot validate that the messages come from an authorized mail server.

The diagram below shows how SPF is used to provide the “Envelope From” information as part  of the DMARC standard.

Suppose a mail is sent with the following address information:

Mail-from: customerservice@example.bank 

From: customerservice@example.bank

To: steve@zelda.example.org

In SMTP, when one mail server connects to another the sending server introduces itself. In our example, let’s say the sending server says HELO mail.boston.example.bank. Now that we know the hostname the sending server claims to be, we can check that. We do that by looking up the SPF record for mail.boston.example.bank, which might look like this:

mail.boston.example.bank.

TXT “v=spf1 a -all”

This record tells us that the only host that can announce itself as mail.boston.example.bank is mail.boston.example.bank (indicated by the “a”). Note if there was no SPF record for mail.boston.example.bank, the result would be None, rather than Pass or Fail.

If the IP address of the sending server matches the IP address of mail.boston.example.bank, we have a Pass result for SPF.

If the IP address of the sending server does not match the IP address of mail.boston.example.bank, we proceed to the next part of the SPF record, -all, which yields a Fail result.

Since the mail-from shows an @example.bank address we look up the following SPF record:

example.bank. TXT “v=spf1 a:mail.boston.example.bank -all”

This record indicates that there is only one server that is allowed to send mail using the example.bank domain, and that is mail.boston.example.bank. Now that we know that, we look up the IP address of the mail.boston.example.bank host.

If the IP address we find for mail.boston.example.bank matches the IP address of the incoming connection, then we have a match and the SPF test yields a Pass result.

If the address does not match mail.boston.example.bank, then we go on to the next part of the SPF record, in this case “-all” which tells us that any other IP address yields a Fail result.

SPF Practical Limitation 

A single SPF record can contain a maximum of 10 DNS lookups to see if you authorize a particular IP address to send mail on your behalf. This practical limitation should be observed to ensure timely delivery of email messages and favorable inbox ratings. There are several ways to avoid this limitation such as:

  • Make use of sub-domains as each is afforded its own 10 lookup max
  • Use separate email address (e.g., corporate, marketing)
    • Send mail from different domains and/or IP addresses

See: https://dmarcian.com/spf-syntax-table/#toomany.

Example: A DKIM Record

The requirement identifies that registrants may use DomainKeys Identified Mail (DKIM) as one of the two options for authenticating email messages in compliance with DMARC. DKIM is an email validation system that allows a mail server to check that a domain is authorized to send a particular piece of email and verify that the message has not be modified during its transport through the network. DKIM works differently from SPF in that DKIM uses a digital signature to sign the message. This signature is added to the content of the message and the recipient can then use it, along with a public key published in the DNS, to verify that the message was sent by an authorized person and that the message has not been altered.

DKIM consists of a signing and verifying application usually built into a mail server.

DKIM requires that there be a public key available for the validation process. It works like this:

myselector._domainkey.example.bank TXT “k=rsa; p=AIGf ... AQAB”

Notice that there is a selector attached to the special domainkey subdomain. Here is a list of the possible options for this text record and their meanings:

  • k = key type (rsa is the default). All Signers and verifiers support the “rsa” key type.
  • n = notes that may be of interest to a human. No interpretation is made by any program. This tag is optional.
  • p = the public-key data, encoded as a Base64 string. An empty value means that this public-key has been revoked. This tag MUST be present.
  • t = testing mode (“y” means that this domain is testing DomainKeys and unverified email MUST NOT be treated differently from verified email. Recipient systems may wish to track testing mode results to assist the sender.) This tag is optional.

With these two special TXT records in the DNS we can now see how DKIM works in practice. The sending server inserts a mail header in the message called the “DomainKey Signature.” Effectively, this is a digital signature over the entire message contents using the private key of the server. A sample might look like this:

DKIM-Signature: a=rsa-sha1; s=myselector; d=example.bank; i=customerservice@mail.example.bank; c=simple; q=dns; b=dydVyOfAKCdLXdJOc8G2q8LoXSlEniSbav+yuU4zGffruD00lszZVoG4ZHRNiYzR;

When this recipient gets the message, the server can look up the public key for example.bank and then calculate whether or not the message contents are the same as what was sent. It also allows the recipient to find out the signing organization’s message signing policy.

We’ve seen how SPF and DKIM can add message authenticity to the sending process. The following diagram shows how DMARC fits into the process.

BINK2_2017 FTLD Implementation Guide-Technical Guidebb.jpg

Example: DMARC in Practice

A DMARC policy uses the DNS to allow a sender to indicate that their emails are protected by SPF and/or DKIM. DMARC also suggests what the recipient should do if neither of those authentication methods passes—for instance, delete, none, quarantine or reject the message.

For an fTLD Domain “,” DMARC removes guesswork from the receiver’s handling of these failed messages. It also provides a user the ability to eliminate fraudulent or harmful messages falsely purporting to come from an fTLD Domain. DMARC also provides an optional mechanism for receivers to report back to the sender about messages they receive with DMARC evaluations.

Here’s an example DMARC record:

_dmarc.example.bank. IN TXT “v=DMARC1; p=reject; rua=mailto:postmaster@example.bank; ruf=mailto:dmarc@example.bank”

Here is a list of the possible options for this text record and their meanings:

  • v = the protocol Version for DMARC—this is a required parameter
  • p = policy for the domain—this is another required parameter and the values can be none (which takes no action), quarantine (which marks messages as spam), and reject (which rejects the message entirely). The fTLD Domain guidelines suggest using p=none when implementing the Requirement for email.
  • pct = the Percentage of the email message that is subjected to filtering › rua = an email Address(es) for the Reports
  • sp = a policy for the subdomains of the domain affected by this DMARC record
    • aspf = the Alignment Mode of SPF
    • adkim = the Alignment Mode for DKIM
    • ri = the Reporting Interval

The alignment modes for SPF enables an administrator to manage which parts of the message are authenticated by either SPF. Alignment, for DMARC DKIM, has to do with whether the signing domain used for the signature must strictly match the RFC5322 “From” domain, or if the signing domain and RFC5322 domains must merely be domains within the same organization domain, e.g., proper subdomains of the org domain, or one the organizational domain and the other a subdomain. Since the alignment can be different in diverse implementations, DMARC allows both “strict” and “relaxed” versions of the alignment with the goal of checking against the MailFrom portion of the incoming message.

The requirement suggests, but does not require, that the identifier alignment for both SPF and DKIM be set to “strict.” Also, the optional pct tag is helpful during implementation. It can be used to stage and sample your DMARC deployment. Since 100 percent is the default, passing “pct=20” in your DMARC TXT record results in one-fifth of all messages affected by the policy actually receiving the disposition instead of all of them.

Tip: Ensure that your organization’s incoming mail service provider/server is properly configured for DMARC and this is on top of having properly formed DMARC and SPF records. For common mail service providers like Gmail, Microsoft 365 (for inbound email only), and Yahoo!, they do this for you. If you use Microsoft 365 with a custom domain or an on-premise Exchange server, you’ll need to manually implement DMARC for your outbound mail (learn more about this here). 

DMARC Deployment for Registrars and Registrants

DMARC deployment and mail authentication can be challenging. However, there is a large body of information available for implementers.

For those organizations running their own mail and DNS servers, there are both commercial and open source tools to add to existing mail servers. For organizations who want to offload the mail services to a separate appliance several message gateways have built-in DMARC support. Several tools have been released that support enterprise-class DMARC support in large scale email tools (e.g., Hexamail Guard for Microsoft Exchange).

For organizations that outsource their email services, there are a variety of third-party providers of hosted email that support SPF, DKIM and DMARC. In addition, it is possible to have a third-party sender relay your mail through a server you provide. Similar to DNSSEC, it is necessary to work with the organization that is hosting your email in order to ensure that when they send email on your behalf it is DMARC compliant.
IMPLEMENTATION HUB