Red Sift Leitfaden zur E-Mail-Protokollkonfiguration

A DMARC TXT record is a text entry in the DNS that instructs the worldwide email servers about your DMARC policy. It also contains information about whom to send XML reports to tell how your email is proceeding through the ecosystem. You must monitor these DMARC reports to detect unidentified and suspicious activities attempted using your domain name. 

A usual DMARC TXT record looks like this:

v=DMARC1; p=none; rua=mailto:example@xyzdomain.com;

Where:

• v (version tag) represents the version of the protocol, and currently, there’s only one version. So, the value is always v=DMARC1
• p (policy tag) shows the domain policy (none, quarantine, or reject) to recipients’ email servers to direct how to treat emails failing SPF and DKIM checks
• The rua tag contains a comma-separated list of email addresses defining where receivers should send aggregate reports

An example of a DMARC record might look like this:

v=DMARC1; p=reject; pct=100; rua=mailto:1234@inbox.ondmarc.com,mailto:dmarc@example.com; ruf=mailto:1234@inbox.ondmarc.com,mailto:dmarc@example.com;

The policy shows that 100% of failed emails should be rejected. It also shows where the aggregate and forensics reports should be sent to.

See the table below for a description and example of each tag that could appear in a DMARC record.

SPF validates the MAIL FROM/Return-PATH domain (or the HELO/EHLO hostname if MAIL FROM is empty) and DKIM validates the domain specified in the d= field of the DKIM headers. If any of the above validates then that means a PASS.

However, DMARC goes a step further as it does not only require SPF or DKIM to PASS but it also requires at least one of the domains used by SPF or DKIM to align with the domain found in the From header. 

In the case of SPF, identifier alignment means that the MAIL FROM/Return-PATH check has to PASS and also the domain portion of the MAIL FROM/Return-PATH has to align with the domain found in the From address. In cases where the MAIL-FROM is empty (found with bounces), alignment is checked against the EHLO domain. In strict alignment, the domains have to match exactly, whereas in relaxed alignment subdomains are also allowed as long as they come from the same organizational domain. 

MAIL-FROM/RETURN-PATH: @ondmarc.com​
From header: @knowledge.ondmarc.com

In the above example, if DMARC was set to strict SPF mode then an email coming from knowledge.ondmarc.com would pass SPF but DMARC would fail as the domains do not match exactly i.e. they are not aligned. However, in relaxed alignment mode, DMARC would pass.

In the case of DKIM, identifier alignment means that the domain specified by the d= field of the DKIM headers has to PASS and align to the domain found in the From header. Again, in strict alignment, the domains in the d= field and From header have to match exactly whereas, in relaxed alignment, subdomains are also allowed as long as they come from the same organizational domain.

d= "ondmarc.com"
​From header: @knowledge.ondmarc.com

In the above example, if DMARC was set to strict DKIM mode then an email coming from knowledge.ondmarc.com would pass DKIM but DMARC would fail as the domains do not match exactly ie. they are not aligned. However, in relaxed alignment mode, DMARC would pass.

A DMARC aggregate report contains information about the authentication status of messages sent on behalf of a domain. It is an XML feedback report designed to provide visibility into emails that passed or failed SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).

The report provides domain owners with precise insight into:

• The authentication results, and
• The effect of the domain owner’s DMARC policy

The report contains the following:

• The domain or organization that sent the report
• The domain that you are receiving the report for and its current DMARC policy
• Date
• Sending IP address
• Email count
• The disposition of those emails ie. the policy that was applied to those emails by the receiver
• The SPF identifier and result, if any
• The DKIM identifier and result, if any

The recipients of your emails will look at the rua tag of your DMARC record and send the reports there. 

For example: 

rua=mailto:xxxxxxxx@ondmarc.com;

You can also specify the aggregate reporting interval by using the ri tag in your DMARC record. By default, this is set to 86400 seconds which equates to 24 hours.

This could be due to a number of reasons:

1. Double-check that you have specified your email address in your DMARC record and that it is correctly formatted. For example, rua=mailto:myemail@example.com
2. Check if you have specified any size restriction in your DMARC record concerning the aggregate reports. For example, rua=mailto:myemail@example.com!10m. You may want to remove the size restriction as some URI parsers may incorrectly parse the “!” in the URI. 
3. Typically reports are sent within the first 24 hours of adding the DMARC record so you might need to allow more time for report generation.
4. If your email volume is very low it may take extra time for the first report to arrive.
5. Your anti-spam filter may be blocking large files of type ZIP.

A forensic DMARC report, unlike an aggregate DMARC report, is a copy of the email that failed DMARC validation on the receiver side. It is typically sent immediately after the failure has occurred.

Any personally identifiable information (PII) is removed from the report, but information that will help in troubleshooting the DMARC failure is included, for example, SPF and DKIM header failure information, the entire From address, and the Subject of the email too.

The address to receive the Forensic DMARC reports is specified by the ruf tag in your DMARC record. 

For example: 

ruf=mailto:xxxxxxxx@ondmarc.com;

You can also specify the type of failures you would like reports for by using the fo tag in your DMARC record. By default, failure reports are sent when both SPF and DKIM fail.

By default, the policy p= tag specified in your DMARC record applies to the domain that it is created under and any subdomains. This means that if your domain is in p=reject, all subdomains of that domain will inherit the policy and will also be in p=reject. Take a look at Scenario 1 below for further explanation.

Let's take the following DMARC record created under the domain protected.com as an example

protected.com DMARC record: "v=DMARC1; p=reject;"

The policy p=reject tag above means that protected.com is in p=reject and any subdomains such as sub.protected.com by default are also in p=reject.

However, the DMARC record syntax allows domain administrators to specify one policy for their top-level domain and a different DMARC policy for their subdomains using an additional tag sp= which stands for subdomain policy. Take a look at Scenario 2 below.

Let's take the following DMARC record created under the domain protected.com as an example :

protected.com DMARC record: "v=DMARC1; p=reject; sp=none"

The DMARC record above states that the domain protected.com has a policy of p=reject, while any subdomains such sub.protected.com and sub2.protected.com have a policy of p=none. 

You can see how a subdomain can have a different DMARC policy without even having a DMARC record itself. So, what happens if the subdomain has its own DMARC record? Take a look at scenario 3 below for the answer.

A subdomain only inherits the DMARC policy of the top-level domain if it does not have a DMARC record itself. This means that even if the top-level domain has p= or sp= tags they do not matter. 

Let's take a look at the following examples:

protected.com DMARC record: "v=DMARC1; p=reject; sp=none" 
sub.protected.com DMARC record: "v=DMARC1; p=reject;"
sub2.protected.com NO DMARC RECORD

You can see that the domain protected.com has p=none subdomain policy specified, sub.protected.com has its own DMARC record with a policy of p=reject and sub2.protected.com does not have a DMARC record. 

In this scenario, sub.protected.com will not inherit the subdomain DMARC policy from the top-level domain because it has its own DMARC record, and therefore will stay in p=reject, while sub2.protected.com will inherit the subdomain policy because it does not have a DMARC record itself. 

Well, it allows domain administrators to protect different domains and subdomains based on how far they are along the DMARC journey. 

For example, if all your email-sending services sending emails on behalf of your top-level domain are fully configured with SPF and DKIM, that means that you can protect your top-level domain with a DMARC policy of p=reject while keeping the subdomains in p=none, and vice versa. 

Also, if you have an email-sending service that is non-DMARC compliant i.e. does not support SPF or DKIM, you may decide to assign a subdomain to it and have that subdomain in a different DMARC policy, without preventing you from protecting your other domains. This allows you to split the traffic across different subdomains and protect each one separately. 

A parked domain is a registered domain name that remains dormant, unlinked to any online service such as a website or email hosting. Essentially, it's a domain name that has been acquired but is not presently in active use; rather, it is parked with the intention of being utilized in the future.

Parking and securing domains that are deceptively similar to your own is considered best practice so attackers cannot use them to pretend to be you. In terms of email, you ideally want to tell your receivers if emails coming from a domain that is similar to yours are legitimate or not.

For example, let’s assume that you have a main domain that you use to send emails, as well as a parked domain that you do not send emails from. You should set up authentication on your main, email-sending domain, as well as your parked domain so that the receiver knows to reject any mail that originates from them should they start sending. 

To achieve this, all of your parked domains should have SPF records in DNS that have the following:

parked-domain.com TXT v=spf1 -all

This SPF record indicates that no email should originate from parked-domain.com. Any emails from this domain should be rejected.

The same should be done for subdomains as well. If you have many subdomains, you can use wildcards (if your DNS allows it):

*.parked-domain.com TXT v=spf1 -all

You can also publish a DKIM record that indicates that no email is signed for a parked domain. You can do this by leaving the p= tag in DKIM empty. This signals that the public key used has been revoked and that the email is not being signed by DKIM at all. For example:

selector1._domainkey.parked-domain.com TXT v=DKIM1; p=

You can also use a wildcard to indicate to recipients that any DKIM selector is revoked for your domain, as shown below:

*._domainkey.parked-domain.com TXT “v=DKIM1; p=”.

This record indicates that any DKIM key has expired for the domain parked-domain.com.

Aside from SPF, you should also publish a DMARC record to indicate the policy for your parked domains but also for you to gain visibility if anyone is using those domains to send emails. You can do this by:

_dmarc.parked-domain.com TXT "v=DMARC1; p=reject; rua=mailto:inbox@ondmarc.com; ruf=mailto:inbox@ondmarc.com;

In the above example, an email from parked-domain.com will be rejected, and aggregate and forensic reports will be sent to ondmarc.com. It also assumes that the parked domain does not receive emails, hence the different domain for the reports.

If you have multiple parked domains you can use a CNAME record to point to a single domain with a DMARC reject policy such as:

dmarc.example.com CNAME _dmarc.parked.example.net. 
_dmarc.parked.example.net TXT v=DMARC1; p=reject; rua=mailto:inbox@ondmarc.com; 
ruf=mailto:inbox@ondmarc.com; 

To indicate that your domain does not accept email you should create a null MX record, rather than having no MX record at all. If your domain does not have an MX record, email delivery will be attempted to the A record of your domain. This is why it’s important to create a null MX record if your has an A record.

Create a DNS record of type MX, with a priority of 0 (highest priority) and a target containing a full stop . as shown below.

Type: MX
Priority: 0
Target: .

For more information on protecting parked domains, read this M3AAWG article.

Responsible disclosure programs (also known as bug bounty programs) are structured frameworks that organizations have in place for security researchers (or bug bounty hunters), to find vulnerabilities within their websites, systems, platforms, or wider attack surfaces. If the bug bounty hunter is successful, the organization compensates them for their findings.

A beg bounty is a term used to describe the surfacing of an easily discoverable issue by a ‘bounty beggar’. These issues aren’t deemed payment-worthy either because they’re not a legitimate vulnerability or are considered an issue that could have been easily spotted by the organization itself.

Missing DMARC records are considered beg bounties. Why? Because DMARC is considered easily discoverable, too complex to implement, and some incorrectly believe it’s unimportant. Some even wrongly believe that DMARC is synonymous with SPF and DKIM.