Implement

How to implement DMARC in three stages: Monitor, Quarantine, then Reject.

Monitor

Monitor your outbound email without affecting current arrangements, gather information and plan for implementation

Ensure your IT department have the processes to manage and disseminate information.

Open lines of communication between email administrators including external agencies.

Set-up external feedback and aggregate report monitoring.

Assess compliance.

Quarantine

Quarantine emails that don't follow your policy.

If there are any edge cases, they can be addressed before setting policy to reject.

Reject

Full benefits of DMARC apply as any email that doesn't follow your policy can be rejected.

Policy documentation

Managing the information required for a successful implementation is straightforward and low maintenance.

DMARC policy is defined by an organisation for each email domain, if there are more domains, then define a policy for each one.

Policies are published in the Domain Name System (DNS) so the records documenting a policy focus on who is the responsible person, what information is to be published, and if there are any time limits. They follow the respective standards dmarc, spf and dkim.

DMARC

Policy domain	Policy	Contact	DNS entry
example.com	none	Admin contact	v=DMARC1; p=none;
p-o.co.uk	quarantine	Admin contact	v=DMARC1; p=quarantine;

SPF

Emails can be sent from anywhere, SPF offers the ability to control where they come from and can reject those that arrive from an unknown location.

Contact	Type	IP address/domain
Admin contact	ip4	80.229.143.200
Admin contact 2	ip6	2a01:348:6:7a1::2/128

A complete entry might look like the following:

v=spf1 ip4:80.229.143.200 ip6:2a01:348:6:7a1::2/128 -all

DKIM

Emails are signed with a private key and are checked with a public key. Only the public key is required.

The following table can be used as the bases for managing and recording public keys in the DNS.

Signing domain	Selector	Contact	Valid until	DNS entry with Public key
example.com	20170101	support@example.com	2018-06-01	k=rsa; p=7nrf1+6oD+KxyIIBIjANBgkqh....BQAMEL
p-o.co.uk	london01	support@p-o.co.uk	2017-12-31	k=rsa; p=MIGfMA0yJToOQDu7FKYseudB....msmiBIQ

The DNS TXT entries to be added are 20170101._domainkey.example.com and london01._domainkey.p-o.co.uk

Although infrequent, keys should be changed by using a new selector on a regular basis, at least annually. Selectors should not be re-used as this would invalidate existing signatures.