JUAL DOMAIN AGED

JASA BACKLINK MALANG

What Is Email Authentication? SPF, DKIM And DMARC Explained

What Is Email Authentication? SPF, DKIM And DMARC Explained

Have you set up email authentication for your domain?

Email authentication involves setting up special DNS records for your domain. It helps improve email deliverability and prevents your domain from being used in spoofing attempts.

In this post, we cover what email authentication is and discuss a few popular email authentication methods: SPF, DKIM and DMARC.

What is email authentication?

Email authentication is a process that helps verify the source of an email.

When spammers attempt phishing scams, they use a tactic known as “spoofing,” which means they use a domain they do not own in an email’s From: header in order to appear legitimate.

Email authentication helps receiving mail servers identify the actual source of an email and respond accordingly if the server discovers a sender is not who they say they are.

Email servers use authentication methods known as SPF, DKIM and DMARC, which are domain name system (DNS) records you can apply to your domain to help authenticate your emails.

Why is email authentication important for email marketing?

Email authentication is important for one primary reason: it prevents your domain from being used in phishing scams.

This protects your customers and helps safeguard your brand’s reputation and spam scores.

Furthermore, email authentication helps prevent your emails from ending up in spam folders or being rejected altogether.

Plus, major email clients like Gmail and Yahoo! have email authentication requirements in place in order for sending servers to successfully send emails to Gmail and Yahoo Mail users.

In order to send email to Gmail users, you must have SPF and DKIM records set up for your domain.

If you’re a bulk sender sending 5,000 emails or more per day, you must have a DMARC record set up as well.

What is an SPF record?

SPF stands for Sender Policy Framework. It’s a type of email authentication receiving servers use to verify that you approve of the servers that attempt to send emails from your domain.

If a bad actor uses your domain in a phishing scam and you have an SPF record set up, the receiving server will be able to determine that the IP address for the scammer’s server does not match the IP addresses authorized for your domain.

It’s the first step in email authentication. If an email does not pass SPF authentication, the sending domain’s DMARC record is called upon to determine what to do with the email.

Here’s how an SPF record authenticates emails:

  1. Server A sends an email.
  2. Server B receives the email.
  3. Server B identifies Server A’s return-path address. This is the email address that receives bounced email notifications for Server A.
  4. Server B searches for the SPF record assigned to Server A’s return-path address.
  5. If an SPF record is found, Server B then identifies Server A’s IP address.
  6. Server B searches Server A’s SPF record to ensure this IP address is listed as an authorized sender for Server A.
  7. If Server B cannot find the IP address in Server A’s list of authorized senders, the SPF check fails.
  8. Server B refers to Server A’s DMARC policy to determine what to do with the email: do nothing, send it to spam or outright reject it.

What does an SPF record look like?

Each domain can only have a single SPF record, but you can use that one record to authorize each server you use to send emails from.

If you send emails from an email client like Google Workspace but also use a service like GetResponse to send email campaigns, you’d include both of these services in your SPF record.

An SPF record is a TXT DNS record. Here’s an example of a record for a domain that uses Google Workspace to send business emails:

v=spf1 include:_spf.google.com ~all

The “v=spf1” part identifies the record as an SPF record since not all TXT records are SPF records. The “include” part identifies Google Workspace as your sending server. “~all” tells receiving servers that addresses not listed in this record are not authorized to send emails from your domain.

If you also use GetResponse for email marketing, your SPF record would look like this:

v=spf1 include:_spf.google.com include:_spf.getresponse.com ~all

You can get pretty technical with your SPF record by including the exact IP addresses that are authorized to send emails from your domain. However, most email services have simplified what you need to include in your SPF record.

To find yours, determine each service you use to send emails with. Their knowledge base or help docs should contain information on how to set up SPF records for them.

If not, contact their support teams for help.

Why are SPF records important?

As domain spoofing, which are forged sender addresses, became more common, finding a solution to that problem became more and more prevalent.

SPF records are that solution, making them vital to domains whether domain owners send email from them or not.

It’s true. Not only does an SPF record help authenticate the emails you send, it also prevents your domain from being used in emails sent by spammers in phishing scams.

To wrap up, an SPF record authenticates that a sender is who they say they are.

What is a DKIM record?

DKIM stands for DomainKeys Identified Mail. It’s a type of email authentication method that uses cryptography to verify the source of an email.

This method relies on two sets of keys: a public key and a private key.

Every email you send has what’s known as a “DKIM header,” which contains data that’s signed using the private key. This becomes your “digital signature.”

You store the public key in your DKIM record, which, like your SPF record, is a TXT record you assign to your domain.

When you send an email, the receiving mail server checks for and obtains the public key in your DKIM record.

That server then uses the public key within your DKIM record to verify your digital signature.

This message identification process determines whether or not your email message or email headers have been altered at some point during transit.

If they have, which can occur when your domain is used for phishing scams, that DKIM check will fail, and the receiving server will refer to your DMARC record to determine what to do with the email: take no action, place the email in the user’s spam folder or reject the email.

What does a DKIM record look like?

Because a DKIM record stores your public key, it’s mostly made up of a string of random numbers and letters:

v=DKIM1; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjU2ztdeR1cyL2GukBaQbNdOu7jP2Lg1PXP+S1WcxUGa7E/qpGX0yTCF40SLTW1ODvAsmosD1JNBtpQF4vXfRyoM4z9s8OhnMD3+qLM/ChSzXe4lBfAhOHGlgWFYk38ON5Ae6OmFpzBUwek+3UEDDJ/RluDEAWkzsW66MazM4OPsmrl/BpNF0xw/m6GiYW5+Y+SM/t+K59Fpa7t6juORedaeaTjw01+nROOrGEwHo78P26LBphxrRltY28NTLgjKT4BwM+BMN2z/RoA7LiMk8Thv+zHoIMDiiwgMX06xqd98u2RjLZeBwZDVV+w2f16EKPVlur935r/L5qjgDdRCpzwIDAQAB

Most TXT records assigned to your domain will simply use your domain as a name.

However, DKIM TXT records must use “[selector]._domainkey” as a name where [selector] represents a specific value your email service provider uses for DKIM.

If you send mail with Google Workspace, your DKIM record’s name should be “google._domainkey”.

Generating a DKIM record

Your email service provider should have a way for you to generate a DKIM record for your domain. You should generate one for each email service you use to send emails from.

Unlike SPF records, you can assign multiple DKIM records to your domain.

When you generate a DKIM record, you’ll be asked to choose between 1024-bit keys and 2048-bit keys.

2048-bit keys are more secure, but not all DNS hosts support them.

Check your DNS host’s help docs or ask them directly for more information on which DKIM keys they support.

If they support 2048-bit keys, choose that option when you generate your DKIM records. Choose 1024 if not.

What is a DMARC record?

DMARC stands for Domain-based Message Authentication Reporting and Conformance, which means it’s the final part of the process involved in authenticating emails.

A DMARC record tells receiving servers what to do if SPF and DKIM authentication methods fail. This is called your DMARC policy.

You can also use it to receive reports on when authentication fails, what happens to your emails when authentication fails and which servers are attempting to use your domain in phishing scams.

What is a DMARC policy?

A DMARC policy is the specific action a receiving server should take with an email that does not pass SPF and DKIM authentication.

These are the three actions you can assign in your policy:

  • None – If SPF and DKIM authentication fail, a “none” policy instructs the receiving mail server to do nothing with the email and allow it to send as usual.
  • Quarantine – Instructs the receiving server to place the email in the recipient’s spam folder.
  • Reject – Instructs the receiving server to block the email from reaching the recipient altogether, not even the recipient’s spam folder.

Here’s an example of a DMARC record:

v=DMARC1; p=quarantine; aspf=s; adkim=s;

To assign a DMARC policy like this to your domain, you must create a new TXT record for your domain and place this policy within it.

Here’s what each part of this example policy means:

  • v=DMARC1 – Defines the TXT record as a DMARC record since not all TXT records are DMARC records.
  • p=quarantine – This is your primary DMARC policy. You can also set it to “none” or “reject”.
  • aspf=s – Sets SPF authentication to strict, but you can also set it to “r” for relaxed.
  • adkim=s – Sets DKIM authentication to strict, but you can also set it to relaxed as well.

Which DMARC policy should you choose?

Because Gmail now requires bulk senders to set up DMARC records for their domains, Google has guidelines on how to enable this type of record.

They recommend setting your DMARC policy to “none” to start out with. This ensures your emails still send as you and receiving servers determine whether or not your emails are passing SPF and DKIM authentication.

There are several additional tags you can add to your DMARC policy, one of which involves adding the email address of a third-party service that can aggregate DMARC reports for you.

These types of reports alert you of failed SPF and DKIM authentication attempts and can even let you know which servers are using your domain for spoofing.

If you set your DMARC policy to “none” when you first add it to your DNS records, you can use these reports to determine if your SPF and DKIM records are operating as they should.

Google recommends gradually setting your policy to “quarantine” before finally setting it to “reject” permanently.

Should you use strict or relaxed alignment?

If you only send emails from your domain and never a subdomain nor an alias, set SPF and DKIM authentication to “s” for strict alignment.

This means you only send emails from [email protected] and never a subdomain like [email protected]. Your return-path address should also match this domain.

If you do send email from a subdomain or your return-path address uses a subdomain of your domain, set authentication to “r” for relaxed alignment.

If you’re unsure, set it to strict while you do testing. If SPF authentication fails, set it to relaxed instead. If DKIM authentication fails, set that to relaxed as well.

How to set up email authentication for your domain

To sum up, here are the DNS records you’ll need in order to set up email authentication for your domain:

  • SPF – Verifies you as an authorized sender for your domain.
  • DKIM – Verifies that your email body and message header have not been altered.
  • DMARC – Tells receiving servers what to do with emails that fail SPF and DKIM authentication.

You can only have one SPF record, but that record should include an SPF tag for every email service you use.

You should have one DKIM record for each email service you use.

Your email service provider should have information on how to create SPF and DKIM records. If not, ask their support teams directly.

Finally, your DMARC record should eventually instruct receiving servers to reject emails that do not pass SPF and DKIM checks, but use “none” or “quarantine” in your policy instead of “reject” until you’re certain that legitimate emails pass SPF and DKIM authentication.

Final thoughts

SPF, DKIM and DMARC are important email authentication methods you can set up for your domain to pass authentication checks and protect your domain from being used in phishing attempts.

Once you set up SPF, DKIM and DMARC records, use email authentication tools to verify that authenticated messages are going through and that you’re passing DMARC authentication.

If you need more help with this, check out our post on avoiding spam filters.

Check out our post on SPF, DKIM and DMARC authentication if you need even more help setting this up.