Configure outbound DMARC

Updated 1 day ago by admin

Email Security provides the ability to participate in DMARC (Domain Message Authentication Reporting and Conformance) for email authentication.

Below configuring any DMARC DNS entry, you must ensure that the following is true:
1. You have enabled DKIM for each domain in your account.
2.
You have enabled SPF for each domain in your account.

Create a DNS Resource Record of type TEXT with a record name like _dmarc.domain.TLD

The record name must start with _dmarc (including the underscore).

For example, the Resource Record name for domain tonyfrankum.co.uk is _dmarc.tonyfrankum.co.uk

The text content of a simple starter record should be similar to

v=DMARC1; p=none; rua=mailto:DMARCReports@tonyfrankum.co.uk; aspf=s
  • aspf=s specifies "strict" checking of SPF (the default is "relaxed").
  • rua= provides the email address to which DMARC reports should be sent.
  • p=none specifies a policy of "none" - the recipient should not reject or quarantine any messages simply because they do not align with this DMARC policy. The recipient could of course reject or quarantine the messages for other reasons.

You should start to receive reports to the email address you specified every 24 hours. After reviewing the reports and confirming that valid messages from your domains do pass evaluation, you may then request that recipients act on messages that do not align with the policy, by changing the policy to quarantine or reject.

Understanding DMARC reports

A DMARC Forensic Report contains the following information

Mail From

The origin of the email.

Authentication

The results from the Mail Transfer Agent.

Delivery Result

Whether the message was rejected, quarantined, or had no policy applied. This is based on the policy outlined in the DMARC record.

From DKIM Domain

The digitally-signed origin.

DKIM Selector

DKIM Body

SPF from domain

IP Information

The IP address that reportedly sent the message.

Time

Time that the message was originally received by the ISP (in seconds).

Message headers

SPF-authenticated Identifiers

DMARC provides the option of applying SPF in a strict mode or a relaxed mode. 

In relaxed mode, the [SPF]-authenticated RFC5321.MailFrom (commonly called the "envelope sender") domain and RFC5322.From domain must match or share the same Organizational Domain. The SPF-authenticated RFC5321.MailFrom domain may be a parent domain or child domain of the RFC5322.From domain. In strict mode, only an exact DNS domain match is considered to produce identifier alignment. 

For example, if a message passes an SPF check with an RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address portion of the RFC5322.From field contains "payments@example.com", the Authenticated RFC5321.MailFrom domain identifier and the RFC5322.From domain are considered to be "in alignment" in relaxed mode, but not in strict mode. 

For purposes of identifier alignment, in relaxed mode, Organizational Domains of RFC5321.MailFrom domains that are a parent domain of the RFC5322.From domain are acceptable, as many large organizations perform more efficient bounce processing by mapping the RFC5321.MailFrom domain to specific mail streams.

DKIM-authenticated Identifiers

DMARC provides the option of applying DKIM in a strict mode or a relaxed mode.

In relaxed mode, the Organizational Domain of the [DKIM]-authenticated signing domain (taken from the value of the "d=" tag in the signature) and that of the RFC5322.From domain must be equal. In strict mode, only an exact match is considered to produce identifier alignment.

To illustrate, in relaxed mode, if a validated DKIM signature successfully verifies with a "d=" domain of "example.com", and the RFC5322.From domain is "alerts@news.example.com", the DKIM "d=" domain and the RFC5322.From domain are considered to be "in alignment". In strict mode, this test would fail. However, a DKIM signature bearing a value of "d=com" would never allow an "in alignment" result as "com" should appear on all public suffix lists, and therefore cannot be an Organizational Domain.

Identifier alignment is required to prevent abuse by phishers that send DKIM-signed email using an arbitrary "d=" domain (such as a Cousin Domain) to pass authentication checks.

DMARC Mechanism Check Result

This is the Alignment Results of DMARC Mechanism Check Result.


How did we do?