Understanding DMARC record
Understanding
DMARC record
DMARC, (Domain-based Message Authentication Reporting, &
Conformance) an open source standard, uses a concept called alignment to
tie the result of two other open source standards, SPF (a published list
of servers that are authorized to send email on behalf of a domain) and DKIM
(a tamper-evident domain seal associated with a piece of email), to the content
of an email.
DMARC alignment
By themselves, SPF and DKIM can associate a piece of email with a domain. DMARC attempts to tie the results of SPF and DKIM to the content of email, specifically to the domain found in the From: header of an email. The domain found in the From: header of a piece of email is the entity that ties together all DMARC processing.
Because anyone can buy a domain and put SPF and DKIM into place (including criminals), the results of processing SPF and DKIM have to be related to the domain found in the From: header to be relevant to DMARC. This concept is referred to as Identifier Alignment.
Are your SPF and DKIM identifiers aligned?
When your email is sent, the “From domain” has your domain name after the @ within the email address. Your DKIM signature should also contain the same domain name embedded into the key string. If they match, then they are aligned. Having the SPF and the DKIM align means your email will pass DMARC verification.
If not already deployed, putting a DMARC record into place for your domain will give you feedback that will allow you to troubleshoot your SPF and DKIM configurations if needed.
Adopting DMARC involves creating a DMARC record, publishing it, and using the information that is generated to gain insight and control over the way your domains are handling email. DMARC helps legitimize your email by doing two things:
·
Gives
feedback about the email itself, including information about SPF and/or DKIM
alignment.
·
Tells
email receivers (like Gmail and Yahoo) how to handle messages that fail to
align with those protocols.
Publishing a DMARC record
To start generating DMARC data, you must first publish a DMARC record for each domain you wish to monitor. A DMARC record exists as part of your Domain Name System (DNS) record, which routes traffic on the internet. You can include additional information in the DNS, like your domain’s DMARC record—a text entry within the DNS record that tells the world your email domain’s policy based on the configured SPF and DKIM protocol.
Once you’ve published DMARC records, DMARC data will typically begin to generate within a day or two in the form of reports that give you insight into the way your domains are handling email. These reports are XML-based and can be difficult for humans to read and make sense of, especially when they can number in the thousands.
For an email message to be considered DMARC-compliant, the domain found in the “From:” header must match the domain validated by SPF or the source domain found in a valid DKIM signature. If the domains match and at least one of the two mechanisms succeeds verification, receivers can safely say that the email legitimately comes from the specified domain.
* If SPF or DKIM is absent, this individual check
will fail, leaving only the other to result in a pass. If SPF and DKIM are
absent, automatic DMARC fail.
DMARC Policy: Policy Modes - Quarantine vs Reject
A DMARC policy allows a domain owner to indicate that their messages are protected by SPF and/or DKIM and tells the recipient what to do if none of these are verified on a particular piece of email, such as marking it as junk mail or rejecting delivery of the message. Domain owners can set their DMARC policy (referred to as “p=”) to determine what is done to non-compliant email:
Domain owners can publish policies that will be applied to email that is not compliant with DMARC:
·
p=none is used to collect
feedback and gain visibility into email streams without impacting existing
flows. It’s a crucial first step.
·
p=quarantine allows email
receivers to treat email that fails the DMARC check as suspicious and files
them in a SPAM folder.
·
p=reject requests that email
receivers reject email that fails the DMARC check.
Quarantine
A DMARC policy set to p=quarantine instructs email receivers to treat email that fails the DMARC check with increased scrutiny. Email is still accepted and it is up to the individual receiver to implement what quarantine means. Possible implementations include the following:
·
Deliver to spam folder: if an
email receiver hosts the recipient’s mailbox, then the receiver might be able
to deliver non-compliant email into the recipient’s spam folder.
·
Temporary quarantine: an
email receiver may choose to temporarily quarantine non-compliant email so that
additional analysis of the email can be performed. An operator may then release
email from quarantine after review.
·
Increase aggressiveness of
anti-spam filtering: Anti-spam filtering is a trade-off between identifying as
much spam as possible versus accidentally identifying wanted email as spam.
Email that falls under a DMARC policy set to quarantine is more likely judged
as spam.
The important thing to know about publishing a quarantine
policy is that non-compliant email is still delivered. Because of non-DMARC
technology that may be present to block spam, the email may or may not arrive
at its final destination, but email will continue to flow from email servers.
The impact of a quarantine policy on non-compliant legitimate email will therefore not be immediately obvious to the sources of such email. The source of legitimate-but-non-compliant email will see a decrease in the performance of their email communications. Because of the different ways the DMARC quarantine policy is implemented, the source’s email will be spam-foldered, delayed, and possibly discarded by email receivers. Unless the source of affected email is paying close attention to its own performance, the impact of quarantine may go unnoticed for a long period of time.
A DMARC policy set to p=reject instructs email receivers to refuse to accept email that fails the DMARC check. There are two known implementations:
Refuse to accept non-compliant email at SMTP time. This is
the preferred and most widely adopted implementation because delivery to DMARC
verifying receivers is prevented. Senders will immediately be informed why
non-compliant email isn’t getting through.
Initially accept email via SMTP and then prevent the final
delivery of the email that fails DMARC. This implementation is less optimal in
that responsibility for delivery of an email has been assumed via SMTP, and yet
the email is eventually not delivered. When delivery fails, one of two things
can happen:
·
a Delivery Status
Notification (aka a “bounce” message) is generated, or
·
the non-compliant email is silently
dropped.
By default, email that falls under a DMARC reject policy is
not delivered. This behavior is a great control against the sending of
unauthorized email.
The impact of a reject policy on legitimate-but-non-compliant email will therefore be immediately obvious – email will stop flowing. When moving to a reject policy, a domain owner should be ready to deal with legitimate sources of email that might run into reject-based policies, as the source of email will surely require assistance in becoming compliant with DMARC.
Troubleshooting: DMARC Record Issues
Issues in a DMARC record may prevent DMARC data from being reliably generated.
Common record issues include:
·
The v=DMARC1 tag is not
optional and is case sensitive. Remember: DMARC1 must be in caps!
·
Addresses inside rua and ruf
tags must be in URI format (i.e. mailto:user@example.com)
·
Your DMARC record must be
located at _dmarc.[yourdomain].com
Forwarders
Forwarding of email happens on the Internet. Forwarding typically happens when you send email to someone@EXAMPLE.ORG and that someone has configured their email to be forwarded to someplace else like someone@SAMPLE.NET. People who have an email address from long ago but have decided to move to a webmail provider often fall into this category. Other examples: people with alumni addresses that get forwarded to someplace else, and mailing lists. In all cases, from the perspective of the email receiver (the one that is generating DMARC XML reports) your email appears to be coming out of infrastructure that otherwise has nothing to do with you.
DKIM signing can survive forwarding. SPF does not work in the context of forwarding, as SPF is simply a list of servers that are authorized to send on behalf of your domain. It is not possible for a domain owner to maintain a list of forwarders.
Sample DMARC record:
Type : TXT
Host : _dmarc.domain.com.bd
Value : v=DMARC1; p=quarantine; rua=mailto:dmarc@domain.com.bd; ruf=mailto:dmarc@domain.com.bd; fo=0; pct=100; sp=none;
What is the pct (percentage) tag in a DMARC Record?
DMARC records are published in the DNS as text records and allow a domain owner to tell email receivers what to do with email that fails authentication based on the DMARC policy. As part of that record, the pct tag tells a receiving server the percentage of email messages in which the stated DMARC policy applies.
Here’s an
example of a DMARC record:
In the example, the DMARC record has instructed the receiving server to reject 80% of email that fails DMARC authentication and to send a report about it to the mailto: address in the record. Here’s a description of the tags in the record:
v – This states the version 1 DMARC record. The version
should always be DMARC1. An incorrect or missing DMARC version tag will cause
the record to be ignored. And that’s not good because the DMARC record will be
ineffective. Here are other pitfalls to avoid.
p – This tag indicates the DMARC policy. Values include
p=none, p=quarantine and p=reject.
·
None is used to collect
feedback and gain visibility into email streams without impacting existing
flows. It’s a crucial first step.
·
Quarantine allows email
receivers to treat email that fails the DMARC check as suspicious. Most of the
time, they will end up in your SPAM folder.
·
Reject does just that—it
requests that email receivers reject email that fails the DMARC check.
rua – The list of URIs for receivers to send XML feedback.
DMARC requires a list of URIs of the form of mailto:address@example.org
Now, more about the pct tag. Though the pct tag is optional
and often shunned, it is an effective way for domain owners to gently and
increasingly enact and test their DMARC policies. It provides an avenue for
ensuring that legitimate email streams are flowing and that illegitimate ones
are not.
It’s worth noting that by using the optional pct tag at less
than 100%, which is the default if no pct tag is included in the DMARC record,
a domain is open to potential spoofing. The ultimate goal is to reach a
p=reject policy at 100%. When you reach that point, you can delete the pct tag
completely since pct=100 is the default if there is no pct tag in the record. A
clean, uncluttered DMARC record in its ideal policy state looks like this:
1. DMARC record not found
Publishing a DMARC record with a policy set not to disrupt
email is the first step of deployment. By not having a published DMARC record,
you not only remain unaware of how your domain is being used outside of your
own monitored infrastructure, but you are not taking advantage of the domain
protection DMARC offers. To publish a DMARC record you can get started here.
2. Policy enforcement on active domain without monitoring
Having a DMARC record with policy enforcement yet no
reporting to monitor the domain (e.g. v=DMARC1; p=reject) doesn’t give you the
visibility you need to maintain your domain protection. Monitoring is key to
understanding who and what is sending email on your behalf.
3. Specifying tags which are implicit
For example, pct=100 is the same as not putting that
tag/value pair in. The same goes for rf=afrf, aspf=r, adkim=r. Adding these
tags and values make the record look more complicated and take up more space
because the TXT record becomes longer.
4. Sending reports to a different domain
Sending reports to a destination which includes a different domain in the RUA and RUF tags without creating an external domain verification record can lead to a security risk. Google, in particular, does not check for this requirement, so you still get reports. But other DMARC reporters follow the specification requirement of not sending reports to destinations whereby the domain in the RUA and RUF tags are different unless the domain in those tags explicitly publishes the external domain verification record in DNS. This record tells the world that it is okay to send DMARC reports about other domains to them. This is a necessary security limitation to prevent DDoS attacks, and it is likely that Google will check for this requirement in the future.
5. DMARC syntax invalid
Here are some points to keep in mind when creating DNS
records:
Don’t forget to place a semicolon between tag/value pairs.
Use p=none and not p=monitor. p=monitor was an early,
pre-publication DMARC policy that was supplanted by p=none, the monitoring
policy.
Specify the mailto: in front of the submission reporting
address.
Make sure the DNS TXT record has the hostname of _dmarc
Place the p= tag after v=DMARC1 — it is required at that
position.
Remove quotes around a TXT record in DNS, though some DNS
providers do accept quotes.
How does DKIM work?
To use DKIM, email servers are configured to attach special DKIM signatures to the emails they send. These signatures travel with the emails and are verified along the way by the email servers that move the emails toward their final destination. These signatures act like a watermark for email so that email receivers can verify that the email actually came from the domain it says it does and that it hasn’t been tampered with.
Each signature contains all the information needed for an email server to verify that the signature is real, and it is encrypted by a pair of keys. The originating email server has what is called the “private key,” which can be verified by the receiving mail server or ISP with the other half of the keypair, which is called the “public key.”
What are DKIM Selectors?
The DKIM selector is specified in the DKIM-Signature header and indicates where the public key portion of the DKIM keypair exists in DNS. The receiving server uses the DKIM selector to locate and retrieve the public key to verify that the email message is authentic and unaltered.
How can I find my DKIM Selector?
A DKIM selector is specified when the private/public key pair is created when DKIM is set up for the email domain (or email sender), and it can be any arbitrary string of text.
The DKIM selector is inserted into the DKIM-Signature email
header as an s= tag when the email is sent. The easiest way to discover the
selector for your domain is to send an email to yourself.
When you open the email, view the “original message” (some
email clients might call this view “raw” or “full headers”) of the email. Your
goal is to view the header information,
which includes DKIM authentication results.
Search the headers for “DKIM-signature” to find the DKIM
signature applied to the message. If there are multiple DKIM-Signature headers,
find the one which contains your domain. This DKIM signature contains an
attribute “s=” which is the selector used. In the DKIM selector example below
we can see the DKIM selector is s2048gl.
An example of a DKIM Selector
There are two forms of reports: RUA reports that provides an
aggregate view of all of a domain’s traffic, and RUF reports that are redacted
forensic copies of the individual emails that are not 100% compliant with
DMARC. While RUA reports show the traffic of the email, RUF reports contain
snippets from the actual emails themselves.
RUF Reporting
RUF data was originally intended to provide domain owners with redacted copies of email that failed DMARC compliance. Domain owners would then be able to identify legitimate email streams that need remediation. Due to privacy concerns involving partial or inadequate redaction, most DMARC report generators do not provide RUF reporting. Furthermore, domain owners in sensitive industries (healthcare, financials, governments) do not ask for RUF reporting to avoid any potential future liability due to partially redacted RUF reports.
In practice, RUF reporting was originally used to power
specific threat intelligence activities due to the near real-time ability to
extract malicious URLs. These malicious URLs could then be processed and fed to
takedown services. Because RUF reporting is largely not provided by DMARC
reporters, effective takedown intelligence based on RUF reporting must be
augmented with specialized data feeds from the larger threat intelligence
community.
RUF data can be useful to gain an understanding into why some legitimate traffic is failing DMARC and to potentially see more detail on how messages abusing your domain are constructed. Because of the limited number of DMARC report generators that support RUF reporting, RUF data is best supplemented with other data streams (e.g., from capturing submissions to abuse@ mailboxes and/or investigating mail logs to trace the origination of email streams).
Reference links:
1.
https://dmarcian.com/send_it_school/
Comments
Post a Comment