Most companies use an email service provider, like Oracle Dyn Email Delivery, to send bulk/marketing and transactional email. In most cases, these services provide you with basic suggestions on how to increase email deliverability.
These should include validation steps like implementing SPF, DKIM, and DMARC. By putting these simple measures into place, they can help boost your sending reputation, inbox placement, and overall deliverability practices. They can also assist email senders with preventing malicious behavior such as spoofing.
Here’s an overview of all three and why they need to be implemented if you send bulk/marketing or transactional email.
SPF (Sender Policy Framework) is simple and effective email validation implemented for the purpose of validating the source of your messages and helping prevent unauthorized users from spoofing your emails. Without this, less than reputable people can pass off malicious emails as your own, negatively affecting your sender and domain reputation, as well as your company brand. These could ultimately land your IP and sending domain on blacklists, or could lead to less than ideal inbox placement.
SPF works by allowing you to specify which Internet hosts and IPs are allowed to send on your behalf. For example, if Company X wants to send through Oracle Dyn, they would need to add a TXT record on their public DNS record. Mail hosts then use this DNS record to cross check against information found within the email’s headers, leading to the acceptance or rejection of the message.
Example SPF record:
v=spf1 include:spf.dynect.net ipv4:220.127.116.11 ~all
DKIM (DomainKeys Identified Mail) is another method of securing your email and preventing spoofing. This feature utilizes cryptographic keys, generated by your email provider, to add digital signatures to your emails. Implementing this allows the recipients’ email hosts to validate this signature against your DNS records, validating that the email came from the domain it has claimed to come from.
When passed, DKIM keys shows the receiving mailserver that the email has not been faked or altered in any way. Again, just like with SPF, DKIM is configured by adding TXT records to your sending domain’s public DNS record — something only Company X would have access to.
k=rsa\; t=y\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNOC035KBgQDIKa3zQfU23nDrx5S4dtep4JSifWanEf aH2QJktatwW8ojA5lw8lWNnOrwhc93HieOnyyOXhaeFii0XfNU2RPArk7xUF4ZVpsne10Ii6yb2h/ zHWrZujqt6CowrdlnhwI/xVb+YToLqmlJiqFMXdcV/Nfgvv3VAhX+pJPbYzYP4QIDAQAB
Then, there’s DMARC (Domain-based Message Authentication, Reporting & Conformance). DMARC is another anti-spoofing feature that builds on top of SPF and DKIM. Although it does not require DKIM, having all three implemented is still highly recommended.
The main goal of DMARC is to fight against direct domain spoofing, which is often seen in email phishing attacks. It creates a more transparent view of the email by allowing the sender and receiver to share information about the message itself and where it should be delivered on the recipient’s end: the inbox (p=none), the spam folder (p=quarantine), or outright rejected (p=reject).
DMARC also allows you to define a policy which lets the receiving server know that the message is protected by SPF/DKIM and how it should handle any messages that fail. Not only does this limit the guesswork going into email authentication but also limits fraudulent emails from hitting your customers inbox.
DMARC differs greatly from SPF and DKIM as it can actually supply reporting back to the users. Results of the domain sending will be sent back to the sender as well so that they can further investigate any issues.
Below is an example of what this looks like within a TXT record, set up to pass everything:
v=DMARC1; p=none; fo=1; rua=mailto:email@example.com;ruf=mailto:firstname.lastname@example.org
While engagement and sending to users who want to receive your email is key, you can contribute to a great sending reputation by implementing SPF, DKIM and DMARC. These are all fairly simple to configure into your sending domain’s DNS records and your email service provider should assist you with any questions you might have.