Configure outbound DMARC
Email Security provides the ability to participate in DMARC (Domain Message Authentication Reporting and Conformance) for email authentication.
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(including the underscore).
For example, the Resource Record name for domain
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=sspecifies "strict" checking of SPF (the default is "relaxed").
rua=provides the email address to which DMARC reports should be sent.
p=nonespecifies 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
Understanding DMARC reports
A DMARC Forensic Report contains the following information
The origin of the email.
The results from the Mail Transfer Agent.
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.
SPF from domain
The IP address that reportedly sent the message.
Time that the message was originally received by the ISP (in seconds).
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 "
firstname.lastname@example.org", 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.
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 "
email@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.