DMARC extends SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) and is stored as a TXT record in the DNS.
DMARC is officially still a draft, but is already supported by many vendors – and it can not hurt.
A very simple DNS entry looks in bind like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=none"
DMARC mailflow:
Source: dmarc.org
A DMARC DNS entry is therefore only useful if a SPF record is defined (I’ve written about it here a few days ago) and outgoing mails are signed with DKIM.
If the SPF or DKIM verification fails, the mail is often rejected or marked as spam. By DMARC the sender can define how strict the recipient should carry out the review and – and this is the decisive advantage – to which addresses a failure report is to be sent.
A SPF record can be easily created online. For DKIM a key pair must be created. The mails are signed with the private key and the public key is stored in the DNS for verification. With ISPConfig everything is now possible, which is required for DMARC (SPF, DKIM and DMARC): ISPConfig – DKIM patch 1.0.
If both conditions are up and running successfully, only the DMARC record is missing . You can easily create such a record with Scott Kitterman´s assistant. If you define under RUA and RUF an email address , you receive after a while reports from different ISPs.
These are with zip compressed XML files that are not easy to read. However, the reports can be converted at dmarcian.com.
Note: If the email address does not match the domain for which the DMARC record is created you must store a special record in the DNS zone that belongs to the email address. Scott’s assistant shows but this special record.
example.com._report._dmarc.external.com. IN TXT v="DMARC1;"
It is recommended that you do not use “reject” as your first DMARC policy. Bette start with “none”. This value has no additional impact on the receiver side, but you will get reports. So you can check your configuration and then switch to “quarantine” or “reject”.