Email has been around, in some form, since 1972, so its about time that it had all the updates needed to make it a modern secure system. It gets used many millions of times a week and is deemed a critical infrastructure by many business. So what can be done to make it just that little bit better

SPF

Sender Framework Policy (SPF) came about in early 2000’s and its a simple DNS record which lists all email servers who can authoritatively send email on behalf of a domain. The records give each server a rating of pass, neutral, soft fail or fail. The receiving email server is expected to check for SPF records and ensure it weights its SPAM score based on the returned rating for the sending server.

Unfortunately SPF has a issue with the modern way of forwarding email, if the return-path is not re-written. This could lead to a lot of false-positive SPAM detections being made. The way to solve this is rely on SRS to sort out your return path.

"v=spf1 ip4:192.192.192.0/24 ip4:100.100.100.100 a -all"

The above is a typical example of an SPF record which would be added as a TXT resource to the root email domain. Before any of the attributes, the following symbol can be used to determine the rating.

• + for a PASS rating. This can be omitted.
• ? for a NEUTRAL rating interpreted like NONE.
• ~ (tilde) for SOFTFAIL, somewhere between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged.
• – (minus) for FAIL, the mail should be rejected.

The following attributes can be used to make up the record, an “all” should only appear as the last entry. Others are available but not common nor recommended.

ALL	Matches always; used for a default result like -all for all IPs not matched prior.
A	Match against an address record (A or AAAA) for the sending email domain.
IP4	Match if the sender is in the given IPv4 address range.
IP6	Match if the sender is in the given IPv6 address range.
MX	Match against the MX record for the sending domain to the sender’s address.
INCLUDE	Reference the policy of another domain. If that domain’s policy passes, this is a pass match. However, if the included policy fails, checking against further attributes continues.

The real power of SPF only comes when combined with DMARC.

SRS

Sender Rewriting Scheme (SRS) was introduced in 2003 to allow emails for be forwarded without breaking SPF. This scheme rewrites the originating email domain on forwarding to match that of the forwarding MTA. I will leave most of the details on this one, but the following shows the format.

Original incoming headers
   sender:     john@example.org
   recipient:  amanda@example.com

Rewritten headers to be forwarded
   sender:     SRS0=HHH=TT=example.org=john@example.com
   recipient:  amanda@example.net

• The prefix of SRS0 indicates this is a rewritten address.
• The hash-based message authentication code (HHH) is calculated against a local server secret, but only part of it is set. The hash can be checked by the forwarding domain should a bounce return.
• The timestamp (TT) is used to mark the address invalid after a few days.
• The recipient, in this case john, is removed from the source sender because it may contain an equal signs. It is left only on the re-written email as it can be processed there.

DKIM

DomainKeys Identified Mail (DKIM) is an authentication method used to sign an email to prove its origin. It came about in 2011 and is a more modern version of SPF.

The authentication is achieved by the sending MTA attaching a digital signature to each mail using its private key. The receiving MTA can check the authenticity of this against the public key, which is stored in a DNS record. It is best practice to have multiple keys recorded at one time and to rotate the keys, replacing one every few months. The multiple keys allows for historic check back should delivery be delayed.

The full technical details of this one are best left for a time when you are implementing this method. It is important to note that the digital signing does not attest to the contents of the message remaining unmodified since transmission.

DMARC

Domain-based Message Authentication, Reporting and Conformance (DMARC) came about in 2015, and is an extension to both SPF and DKIM.  It allows the owner of a sending domain to publish a policy in their DNS records which will specify if DKIM, SPF or both is employed. It specifies how to check the from field in the source email, how the receiving MTA should deal with failures, and a reporting process for actions performed under those policies.

The power really comes from pulling all both SPF and DKIM together, along with the ability to produce a report back to the originating MTA on how your domain is being used. This is a great tool for working out if your email domains are being spoofed by others, however, as is usual, there are some downsides. Not every receiving MTA will honour the reporting process (like Microsoft O365), and the XML format of the return reporting requires software to fully analyse your email situation.

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.net;"

The above example shows the reporting being listed for aggregated daily reports, which is simple enough if the report is being sent to an address within the same domain. It is possible to send to a third party domain, but both sides must have matching records to accept this.

The full technical complexities are best left to any of the main sites out there that check and construct these records for you. I like using https://dmarcian.com/dmarc-record-wizard/ but there are others.

As a free option, the above site also offers a report reviewer to take the XML and show it in a human readable format, great for a one off, but much more is needed to check all the daily reports from your main domains.

Overall

I would recommend using all four of the above systems, as I know it will reduce the amount of phishing emails that will go around in your name. It may not reduce the amount of SPAM you receive, but it will allow others to ensure that emails coming from you really are from you.

Clearly start small, put your SPF record in, but ensure a ~all at the end so as not to block things you have not found out about yet.

Then add DMARC in report only mode, and see over period of a month, how your domain is being used. Once you have bottomed out all the surprises, look to turn on DKIM on your sending MTAs, and firm up your policies into Quarantine mode.

After another month I would then recommend turning on to full reject mode.

I hope this will help give you some peace of mind that if the receive wants to check, they will know for certain if the email came from a place you trust to send your email.