SPF, DKIM, and DMARC
SPF, DKIM, and DMARC, are mechanisms designed to reduce forged email. They are increasingly used by mail providers to filter mail, so it is important to enable them for your domain in order to ensure that mail you send is delivered reliably.
Be aware that with these configurations in place, receiving servers are expected to reject mail that purports to come from your domain but is not sent by Mythic Beasts' mail servers.
You should be sure that this is what you want before configuring SPF and DKIM following the instructions below. Two particular things to think about are websites that may legitimately send mail using your domain name, and forwarding.
If you utilize any third-party solutions for sending email from your domain (for example Microsoft / Office 365, Mailchimp, SendGrid), you should contact these providers for additional instructions.
Should you have more complicated requiremen ts, or any questions at all, please email us for help.
SPF
Sender Policy Framework (SPF) is a mechanism to specify which mail servers should be allowed to send mail from a domain.
Simple SPF
If your domain is hosted with Mythic Beasts, and you only send mail from your domain using Mythic Beasts' mail servers, then enabling SPF is very simple:
- Go to the Hosting and Shell Accounts section of the Customer Control Panel.
- Select your hosting account.
- Under the Hosted domains section, follow the Email settings link next to your domain name.
- Press the Use Mythic Beasts SPF button.
Custom SPF
If DNS for your domain is not hosted with Mythic Beasts, or you send outgoing mail via mail servers other than our own, then you will need to configure SPF manually.
We publish an SPF record which you can use if your outgoing mail is sent via Mythic Beasts' mail servers, at _spf.mythic-beasts.com.
You should use the SPF include: mechanism to reference this record from
your own SPF record. Normally your SPF record will need to go at the root of
your domain, which is named as @ in the DNS. So your overall SPF
record might look like this:
@ TXT "v=spf1 include:_spf.mythic-beasts.com -all"
Be aware that, as stated above, this record tells receiving servers that they are expected to reject mail that purports to come from your domain but is not sent by Mythic Beasts' mail servers.
If you need a more complicated SPF record, please feel free to email us for help. The ultimate reference is the SPF standards track RFC.
Note that this record ends with -all, which indicates a fail. If you are
publishing an SPF record for the first time, you might prefer to replace -all
with ~all which is the less drastic softfail. Unfortunately it can be
hard to evaluate the impact of SPF records, since their effect takes place at
the receiving end.
Note that you should use a TXT record. There was once an SPF record type, but (for complicated and controversial reasons) this is now deprecated, and is no longer supported by our control panel.
DKIM
Domain Keys Identified Mail (DKIM) is a mechanism by which mail servers can digitally sign an email such that recipients can verify that mail claiming to be from a particular domain has been sent from a mail server authorised by that domain's owner.
You can enable DKIM as follows:
- Go to the Hosting and Shell Accounts section of the Customer Control Panel.
- Select your hosting account.
- Under the Hosted domains section, follow the Email settings link next to your domain name.
- If the DNS for your domain is hosted by Mythic Beasts, click the
Enable DKIM button -- we'll add DNS records as required.
- If your DNS isn't hosted by Mythic Beasts: Under the DKIM section, you'll find the records you need to add to your domain through your DNS provider. You should ensure these are in place before clicking the Enable DKIM button.
DMARC
Domain-based Message Authentication, Reporting and Conformance, is an additional mechanism to additionally protect your domain from unauthorised usage; typically spam and phishing attempts masquerading as from your domain(s).
DMARC provides instructions to other mail servers on how to handle any messages that fail SPF checks and/or DKIM signatures (including missing any signatures).
Adding DMARC records should be done with care, as they can and do affect the deliverability of your messages. If you are uncertain at any point, please email us for help.
Like SPF, this is expressed in DNS using TXT records. Unlike SPF, this uses a specific hostname instead of the root or bare domain; _dmarc or for example _dmarc.example.com.
Trivial DMARC policy
In 2024, a number of large mail providers introduced additional filtering on
mail from domains with no DMARC policy at all. The simplest fix for this is to
add an explicit "no policy". This can be done by creating a TXT record for
_dmarc.example.com with a value of v=DMARC1; p=none;. Your overall DMARC
record would look like this:
_dmarc TXT v=DMARC1; p=none;
Active DMARC policy
If you are confident that SPF and/or DKIM are correctly enabled for your domain, then we would recommend an active DMARC policy that instructs recipients to quarantine or even reject mail that does not pass the necessary checks.
Your overall DMARC record may look like this:
_dmarc TXT v=DMARC1; p=quarantine;
This can be broken down as:
v=DMARC1- indicates this TXT record contains a DMARC policyp=quarantine- includes that mail servers should "quarantine" messages which fail DKIM and SPF checks and consider them to potentially be spam.- There are other options available -
p=reject, which instructs mail servers to block messages, andp=none, which allows messages to be delivered even if DKIM and SPF checks fail.
Each flag must end with a semi-colon (;).
Other advanced flags are availalable to control how messages are handled; although not covered in this article, we find a good reference for this is the DMARC Record Wizard on dmarcian.com.
DMARC reports
Receiving mail servers may be instructed to collate reports on message deliveries; typically these are sent once per day, per server. We do not recommend enabling this flag as the reports are sent in a computer parsable format that may be difficult to interpret.
However, this may be useful for testing and monitoring as it provides details on both passes and failures; we suggest using a third-party service which can parse these reports down to a more digestable form.
Here is an example that instructs mail servers to send reports to postmaster@example.com:
rua=mailto:postmaster@example.com;
A full DMARC record may look like:
_dmarc TXT v=DMARC1; p=quarantine; rua=mailto:postmaster@example.com;