When you send an email, do you ever wonder what happens to it after you hit 'send'? The email disappears for most people, and they get on with their lives. An email's journey is critical for businesses and marketers interested in inbox delivery. If an email doesn't reach its destination quickly or gets lost forever, the sender may never know what went wrong. But if they do, there's a good chance it will be unpleasant, like a phishing attack or spam folder. One way to do this is to implement email authentication protocols like SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). These technical measures help email clients verify the legitimacy of incoming messages to prevent phishing and spoofing attacks. This article will answer that question and help you confidently implement email protection strategies to secure your email domains, prevent phishing, and ensure reliable email delivery without technical confusion.

Inframail's email infrastructure can help you achieve your goals by boosting your email security and improving your deliverability rates to prevent attacks and unwanted interruptions.

Table of Contents

• What's the Difference Between SPF and DKIM?

• Should I Use SPF or DKIM for Alternate Domain Authentication?

• How Does DMARC Work with Both of These Protocols?

• Start Buying Domains Now and Setup Your Email Infrastructure Today

What's the Difference Between SPF and DKIM?

DKIM stands for DomainKeys Identified Mail, which, as mentioned above, is simply an authentication method explicitly designed to detect when a sender's email address has been forged. Forging sender emails is a process known as email spoofing, which is used frequently in:

• Email spam

• Phishing scams

DKIM acts like a gatekeeper to validate the authenticity of email messages.

DNS & Security

As each email is sent, it’s signed with a private key, validated by the receiving email server or Internet Service Provider (ISP) using a public key called the Domain Name System (DNS). The DNS translates domain names into IP addresses, which is a fancy way of saying it allows you to use your web browser to:

• Locate websites 

• Receive emails

Its chief responsibility is ensuring the email message is not altered during transit. Email altering mid-transit is a genuine problem that occurs more often than you think.

DKIM & Fraud

If you were sending an attachment with your bank account and routing number and didn’t use the correct security protocols, it could be intercepted by a fraudster. Once intercepted, this hacker could insert their account and routing number and send it back to the intended recipient. The recipient would still think it came from you and pay the incorrect bank account instead. With DKIM, the unique private key used to sign emails is stored exclusively on your email server and must be kept secret and secure. If nefarious individuals got their hands on your secret key, they’d have no problem forging your DKIM signatures and using them for fraudulent activities.

DKIM & Reputation

Later in the sending and receiving process, ISPs verify the integrity of messages by fetching the corresponding public key from a specific DKIM record stored in your DNS. The cryptography behind the scenes here is used in SSL, guaranteeing that only messages signed with your special private key will pass the public key check. Another lesser-known benefit that DKIM offers is that ISPs, like Gmail, can use this information to build a reputation score for your domain. If you’ve got top-notch sending practices, you’ll get a higher score. These practices include:

• High engagement

• Low spam

• Minimal bounces

DKIM & Spam

If you’ve scored low with poor practices, it’s less likely your emails will be delivered correctly, almost guaranteeing that they’ll end up in that lowly spam folder nobody checks.

SPF: The Email Authentication Protocol That Will Help You Prevent Spoofing Attacks

Sender Policy Framework, or SPF, is how ISPs such as Gmail and Yahoo verify that a particular mail server is authorized to send emails to a domain. It’s a whitelist: a list of things considered trustworthy or acceptable for services allowed to send emails on your behalf. Similar to DKIM, SPF functions via DNS. Let’s say you use a service like Mailshake to send out marketing emails. You’d then insert a DNS record that includes Mailshake’s mail servers as a whitelisted trusted source to send emails on behalf of your domain.

SPF is critical to verifying who’s allowed to send emails on behalf of your domain and directly impacts your email delivery. Not only do you need it for email marketing and your company email accounts, but it’s also essential for support services such as:

• Helpscout

• Zendesk

• Anyone else sending emails on your behalf

DKIM vs. SPF: What Are the Key Differences?

It’s not all that hard for a hacker to figure out how to send email from your domain. To protect yourself from such malicious activity, you’ll want to set up both:

• SPF

• DKIM.

DKIM is a set of keys that tell IPs you’re the original sender, and nobody fraudulently intercepted my email. SPF is a unique whitelist that includes everyone authorized to send messages on your behalf. If you’re curious to see this all in action, you can verify whether an email is properly signed with DKIM or passing SPF by checking the email headers. You can see this in Gmail using the Show Original option under settings. At the top, you should see PASS next to SPF and DKIM.

Why Are DKIM and SPF Important for Cold Email?

Cold emails are easy pickings for email spam filters. The recipient doesn’t know you, so they’re more likely to leave your emails unread or mark them spam, which ruins your online reputation. If you’re looking for a way to steer clear of the spam folder, then SPF and DKIM are your allies. You can think of SPF as a VIP travel pass to the recipient’s inbox. With it, email deliverability increases, and your email is far more likely to avoid:

• Bulk email filters 

• Spam inboxes

SPF & Security

Having an SPF record also ensures that your reputation stays high because it’s far less likely to get hijacked by fraudsters looking to profit off your good name. Also, if you’re looking to step up your cold email game by investing in email automation software, you’ll have to hand over the keys to your email account to a third-party provider.

SPF & DKIM

Since the email is going through an intermediary, you can count on ISPs to flag it as fraudulent unless you give the proper clearance. That’s where SPF can help – it’s similar to giving your trustworthy friend a key to your house. DKIM is also crucial for cold email since it is a key of sorts. It’s not a key to sending emails like SPF, but a key to opening them. DKIM is an invisible signature that ISPs use to form a reputation score, so your email is less likely to end up in the spam folder.

Deliverability & Success

The best cold email in the world is only valuable if it reaches its target. Ultimately, SPF and DKIM ensure that your reputation stays high and that your cold email shows up when and where you want it.

Related Reading

• Why Are My Emails Going To Spam
• Email Deliverability Rate
• Email Monitoring
• Email Deliverability Issues
• Email Quality Score
• Bounce Rate in Email Marketing
• How To Avoid Email Going To Spam
• Why Do Emails Bounce
• How To Check If Your Emails Are Going To Spam

Should I Use SPF or DKIM for Alternate Domain Authentication?

DKIM and SPF are the two key players in email authentication. They work best together to prevent spoofing and phishing attacks that can wreak havoc on your business.

Is It DKIM vs. SPF—or Both?

Should the battle be DKIM vs. SPF? While not mandatory, using both SPF and DKIM to protect your email domains from spoofing attacks and fraud while increasing your email deliverability is highly recommended.

How Does Domain Spoofing Work? 

Email spoofing is the forgery of an email header so that the message appears to have originated from someone or somewhere other than the actual source. The goal of email spoofing is often to fraudulently obtain the recipient's sensitive information, such as:

• Credit card details

• Password

Such an email often includes a scary message warning the recipient that a security breach has occurred and prompting him to take immediate action.

Phishing & Loss

Seeing that the From address is, like, support@trustedbank.com, a forged email address, the recipient clicks a link in the email and is taken to a malicious website masquerading as the bank's official web portal, and enters his credentials. The malicious website can then use the credentials and withdraw money from his bank account, inflicting financial loss upon the victim.

Spoofing & Invoice

Or, the spoofed email could appear to be coming from one of the victim company's partners while the attacker sends it. The email sends an invoice to the recipient requesting payment. The recipient is redirected to a fake website and pays the invoice without knowing he is wiring money to the attacker instead of the intended partner. What's more, fraudsters can pretend to be the senior management officers of victim companies and send fictitious emails to the staff (such as accounting officers or managers), claiming that money needs to be transferred to overseas business partners or made in business investments.

Fraud & Example

The fraudsters then direct the staff to transfer the company's funds to the bank accounts designated by the fraudsters. The following is a real-life example of a spoofed email: In this email, the attacker, impersonating Google, warns the recipient of a suspicious login attempt and asks him to confirm to steal the recipient's credentials.

How to Stop Email Spoofing/Phishing?

While the reality of rampant email spoofing attacks might seem scary to some, the good news is that you can prevent or block email spoofing/phishing by implementing email authentication with modern email security measures, namely:

• SPF

• DKIM

• DMARC

These protocols serve as the holy trinity of email authentication, and when deployed correctly, they can completely stop email spoofing attacks. On the highest level, an SPF/DKIM/DMARC implementation works by publishing DNS records for the domain to be secured. Together with email service providers (ESP) like Gmail, it prevents unauthorized attackers from delivering spoofing emails using your domain.

Do I Need DKIM and SPF?

Quick answer: If you are serious about email, you do.

But email spoofing and phishing are far-fetched. Even if your organization is lucky enough to stay off the spoofing/phishing radar for a while, implementing DMARC, DKIM, and SPF still offers these instant benefits: 

• Microsoft Office 365 has updated its anti-spoofing policy so that unauthenticated emails go to the spam folder by default, which means if you have not set up DMARC/DKIM/SPF on your domain

• Emails originating from it are likely to not land in the inbox

• A warning message like the following is displayed to the end-user
  
  

Gmail marks unauthenticated emails as such with a red question mark like this–our research has shown that implementing a p=reject DMARC policy boosts email deliverability by 10% or even more with some mainstream mailbox providers, including Gmail.

ROI & Security

In other words, this single act of implementing p=reject increases your email campaign return by 10%. After all, your emails have to make it to the inbox. SPF, DKIM, and DMARC work together to protect your brand and your users from:

• Email spoofing 

• Phishing

A Typical Business Email Scenario

When your business communicates with its employees or customers via email, you outsource email delivery to a third-party service like SendGrid. It is highly recommended to do so, as you will reap numerous benefits, including better deliverability, anti-spam, etc. Here is what happens when you send a business email message to a recipient using a 3rd-party service–you call the email delivery service (like SendGrid) with parameters like:

• Recipient's email address

• Subject

• Message body

• Possibly attachments

With all the data:

• The email delivery service host initiates an SMTP session with one of the servers hosted by the recipient's email service provider, such as Gmail

• The email service provider checks the incoming request, finds the business domain, looks up the SPF/DKIM/DMARC records from the business domain's DNS entries, and performs authentication checks

• Depending on the check results, the email can land in the inbox, be moved to the spam folder, or be rejected outright

A Real-World SMTP Transaction 

Take a look at a real-world SMTP transaction between the email delivery service host and the receiving email server:

• The host issues the hello command to identify itself. You can interpret it as saying, "Hi, I am dmarcly.com." 

• The host then issues the mail from the command to initiate the email transfer and identify the sender. 

• The address specified in this command is called the envelope from address, and it tells mail servers where to return or bounce the message back to, if the message fails to deliver for whatever reason (recipient email account not found). 

• It issues the rcpt to command to specify the recipient. 

• This command can repeat multiple times, with each one for each recipient if there are numerous. 

• The data command starts sending the actual message. 

• The system accepts everything following the data command until it sees a single dot . on its own line, followed by a blank line.

Headers & Body

You can specify header fields familiar to many email end users within this command: 

• From: This is the header from the address, and it appears in many email clients as the email sender. If omitted, it's the same as the envelope from the address. In this transaction, the recipient perceives the sender as john@dmarcly.com

• Reply-to: optional header field to direct replies to the specified address

• Subject: the message's subject shown in the email client

The rest is the message body. Email authentication has little to do with the message body. It's mostly about email header fields and SMTP commands.

Anatomy of an Email Message

An email message consists of a header, which in turn consists of multiple fields and a body. The header contains the information we need to track a message's origin and authenticity. We're interested in the header part here as it's relevant to email authentication. If you are using Gmail, you can use Show original to examine the details of an email message.

A Tale of Two From Addresses

Each email message comes with two from addresses: 

• The envelope from

• The header from

The envelope from address is the address specified by the mail from command during an SMTP transaction. It is also known as MailFrom, RFC5321. From, RFC5321.MailFrom, bounce address, reverse path, return path, return address, From_, Errors-to (and probably more).

From Header Field

The header from address is the address specified in the From header field in the data command. It is also known as:

• RFC5322

• From

• Display from

• Some other variants

The header from address appears in most email clients. Check the following example, where Gmail displays the header from address as the sender:

SPF Works

To facilitate our discussion, let's assume this setup: 

• Your business domain is business.com

• You will send emails to your employees and customers from support@business.com

• Your email delivery server, which sends the email for you, has an IP address of 192.168.0.1

• Some attackers use scam email servers at IP address 1.2.3.4 to try to send spoofed emails.

When an email delivery service connects to the email server serving up the recipient's mailbox:

• The email server extracts the domain name from the envelope from address. In this case, it's business.com

• The email server checks the connecting host's IP address to see if it's listed in business.com's SPF record published in the DNS. 

• If the IP address is listed, the SPF check passes; otherwise not.

SPF & IP

The SPF record looks like this: v=spf1 ip4:192.168.0.1. This means only emails from IP address 192.168.0.1 can pass the SPF check, while all emails from any IP address other than 192.168.0.1 will fail. Therefore, no email from the scam server at IP address 1.2.3.4 will ever pass the SPF check.

How to Implement SPF 

Creating an SPF record SPF provides mechanisms, qualifiers, and modifiers to allow domain administrators to specify IP addresses in a highly flexible way. The record: v=spf1 ip4:192.168.0.1 -all v=spf1 defines the version of SPF. It's always "spf1". Everything that comes after is combinations of mechanisms, qualifiers, and/or modifiers that specify if a host is eligible to send emails. The ip4 mechanism specifies an IPv4 address range allowed to send emails for the domain.

SPF Mechanisms 

In this case, a single IP address 192.168.0.1 is allowed. The -all part at the end specifies that if none of the previous mechanisms matches, the SPF check fails. -all consists of the - qualifier and all mechanisms.

A mechanism is a way to specify a range of IP addresses. Eight mechanisms are defined: 

1. IP4 : If the sender is in a given IPv4 address range, match

2. IP6: If the sender is in a given IPv6 address range, match

3. A: If the domain name has an address record (A or AAAA) that can be resolved to the sender's address, it will match

4. MX: If the domain name has an MX record resolving to the sender's address, match (i.e. the mail comes from one of the domain's incoming mail servers)

5. PTR: If the domain name (PTR record) for the client's address is in the given domain and that domain name resolves to the client's address (forward-confirmed reverse DNS), match. This mechanism is deprecated and should no longer be used.

6. EXISTS: If the given domain name resolves to any address, match (no matter the address it resolves to). This is rarely used. Along with the SPF macro language it offers more complex matches like DNSBL-queries.

7. INCLUDE: References the policy of another domain. If that domain's policy passes, this mechanism passes. However, if the included policy fails, processing continues. To fully delegate to another domain's policy, the redirect extension must be used.

8. ALL: Matches always; used for a default result like -all for all IPs not matched by prior mechanisms.

SPF Qualifiers 

A qualifier specifies the result of a mechanism evaluation. Each qualifier can be combined with any of the mechanisms described above. + for PASS, i.e., the SPF check passes. This can be omitted; e.g., +mx is the same as mx; ? for a NEUTRAL result interpreted like NONE (no policy); ~ (tilde) for SOFTFAIL, a debugging aid between NEUTRAL and FAIL. Messages that return a SOFTFAIL are accepted but tagged; - for FAIL, i.e., the SPF check fails.

SPF Modifiers

There are two widely deployed modifiers: exp=some.example.com gives the name of a domain with a DNS TXT record (interpreted using SPF's macro language) to get an explanation for FAIL results. Rarely used. redirect=some.example.com can be used instead of the all mechanism to link to the policy record of another domain. SPF modifiers allow for future extensions to the framework.

Example SPF Records 

You can modify it to suit your needs. v=spf1 a mx include:_spf.example.com -all This record allows the following IP addresses to send emails on behalf of your domain business.com: 

• If business.com has an address record (A or AAAA) that can be resolved, the resolved value is allowed (the a mechanism)

• If business.com has an MX record that can be resolved, the resolved value is allowed (the mx mechanism)

• Any IP address passing SPF authentication using another domain's SPF record at _spf.example.com, is allowed (the include:_spf.example.com mechanism) 

Publishing an SPF Record 

Once you've created the SPF record, you need to publish it to the DNS before the receiving email server can receive it. Publishing an SPF record is creating a TXT record on your domain.

SPF DNS Lookup Limit

Each time an email message hits the email service host, the host looks up in the DNS to perform SPF check. Care has been taken to prevent this from turning into Denial of Service (DoS) attack. The SPF specification imposes that the number of mechanisms and modifiers that do DNS lookups must not exceed ten per SPF check, including any lookups caused by the use of the include mechanism or the edirect modifier.

What If Your SPF Record Exceeds the 10-DNS-Lookup Limit? 

If your SPF record exceeds the 10-DNS-lookup limit, SPF authentication returns a permanent error indicating too many DNS lookups. An SPF permanent error is interpreted in DMARC as fail. When this happens, it hurts your email deliverability.

DKIM: The Other Email Authentication Protocol

DomainKeys Identified Mail (DKIM) is an email authentication method that helps prevent spoofing. It works by affixing a digital signature to outgoing emails, allowing receivers to check that the email actually came from the sender's domain and hasn't been tampered with during transit.

How DKIM Works

One important aspect of email security is the authenticity of the message. An email message usually goes through multiple servers before it reaches the destination. How do you know the email message you got is not tampered with somewhere in the journey? An email is sent from company 1 to company 2 requesting a 1000 USD payment to company 1's account. Some hacker alters the email downstream so that the request becomes 100,000 USD to another account, and without extra security measures, it's hard to detect such alterations.

DKIM & Forgery

DKIM comes to the rescue. DKIM, which stands for DomainKeys Identified Mail, is an email authentication method to detect forged header fields and email content. DKIM enables the receiver to check if email headers and content have been altered in transit.

DKIM Signing

Signing an email message on the originating email server means: 

• Choose which header fields and/or body to be included in the data

• Compute the hash sum of the data, including message headers and message body

• Encrypt the hash sum with the private key

The result is called the signature; append a DKIM-Signature header containing the signature to the email.

DKIM Verification

When the email reaches the destination, the receiver checks if a DKIM-Signature field exists in the header. Here is an example of the DKIM-Signature header field revealed in Gmail–DKIM signature header field in Gmail. 

If a DKIM-signature field is found, the server verifies the authenticity of the email:

• Look up the DKIM record of the domain in the DNS, using the selector in DKIM-Signature specified by the s= tag

• If found, extract the public key which is part of the key pair from the record

• Here is an example DKIM record retrieved by a receiving server

• Compute a hash sum using the algorithm specified by the a= tag, of the incoming data specified by the h= tag

• Decrypt the signature with the public key to reveal the hash sum computed by the sender

• If hash sum in 4 is equal to hash sum in 3, it passes the check, meaning the message hasn't been tampered with, otherwise it fails

Tags in DKIM-Signature

The DKIM-signature header field in an email message header consists of a list of tag=value parts. 

An example DKIM-signature header field looks like this: 

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938; h=from:to:subject:date:keywords:keywords; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

DKIM & Tags

Here are the tags that can appear in a DKIM signature header field: 

• v: version

• a: signing algorithm

• d: domain

• s: selector

• c: canonicalization algorithm(s) for header and body

• q: default query method

• t: signature timestamp

• x: expire time

• h: header fields - list of those that have been signed

• bh: body hash

• b: signature of headers and body

Tags in DKIM DNS Record

A DKIM record published in the DNS consists of a list of tag=value parts. An example DKIM DNS record looks like this: 

v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCnVgd0NyrRE261IIiPqi+0H1baNyKcdj8Kea/VlSP4exzvKxJ01EWMwd094FV/6OCBIf7KGKgowMnWl3tW3Z5G++uZHkdgF+6xg7b9PynmX/NTo2kx92hlGgegwyulF5B7d2FM0doaCeoO4rD05jZzwi3cXx/156Gg9Xwd/Z/QIDAQAB 

Here are the tags that can appear in a DKIM DNS record: 

• v: version; must be "DKIM1"; 

• g: granularity

• h: a list of mechanisms that can be used to produce a digest of message data

• n: notes that might be of interest to a human

• s: a list of service types to which this selector may apply

• q: a list of query methods; l: body length limits

• k: a list of mechanisms that can be used to decode a DKIM signature

• t: a list of flags to modify interpretation of the selector

• p: base64 encoded public key

Creating a DKIM Record

If you are using a 3rd-party email delivery service, creating a DKIM record is easy enough: simply use their service to create the private/public key pair that will be kept with their service. 

This is how to do this in SendGrid now:

• Log in to SendGrid' dashboard

• Go to Settings/Sender Authentication/Authenticate Your Domain

• Choose your DNS host and click the Next button

• Authenticate email domain in SendGrid

Publishing a DKIM Record 

Before an email receiver can authenticate your domain using DKIM, you need to publish it to the DNS since the receiver queries the DNS for DKIM records. Publishing a DKIM record creates a CNAME record on (selector)._domainkey.example.com. 

This is how to do this step by step in GoDaddy:

• Log in to GoDaddy

• Click the domain in question, then click the DNS button

• Update DNS in GoDaddy 

• If the DKIM record doesn't exist on the domain, click the Add button under the Records section. 

• Add DNS record in GoDaddy

DKIM Key Rotation

DKIM has proven to be a highly effective means by which a receiver can verify that the signed fields of an email have not been modified in transit. However, DKIM is as secure as the weakest link - the private key. One of the best-known uses of asymmetric cryptography is digital signatures, in which a message is signed with the sender's private key and can be verified by anyone with access to the sender's public key.

DKIM & Tampering

This ensures that the message has not been tampered with, as the signature is bound to the message. Verification will fail for practically any other message, no matter how similar to the original message.

Related Reading

• DMARC vs DKIM
• Importance Of DMARC
• What Is a Soft Bounce Email
• Email Deliverability Checklist
• What Affects Email Deliverability
• Why Is Email Deliverability Important
• Email Bounce Rate
• Fix Email Reputation
• Improve Sender Reputation
• Email Hard Bounce
• Email Deliverability Tools
• Email Deliverability Best Practices
• Best Email Domains

How Does DMARC Work with Both of These Protocols?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. This bizarre-sounding acronym identifies an email security measure that protects your domain against being used by the bad guys and gives you better control of your email deliverability. DMARC is based on the SPF and DKIM mechanisms.

DMARC allows you to conclude if an email you got was legitimately sent by the person who claims to have sent it. That’s the authentication part. If the email doesn’t pass the DMARC test, it will be handled in line with the DMARC policy set by the receiver (I describe it in detail later on in the article).

DMARC & Reports

That’s the conformance part. DMARC also allows the receiver to send reports to the sender, describing how the message was handled. Was it sent through to the main inbox, did it end up in a spam folder, or was it rejected? And that’s the reporting part. DMARC allows email receivers to check if the incoming email matches what they know about the sender. If it doesn't, it tells the receivers’ servers what to do with the message.

Why Does DMARC Matter? 

There are three reasons why DMARC is so valuable for email users:

1. It’s A Safety Measure 

On the sender’s end, it protects your domain against unauthorized use by phishers who try to steal your personal information this way. On the receiver’s end, it makes it harder for fraudulent emails to reach your main inbox. DMARC protects against domain spoofing, which occurs when somebody who isn’t allowed to use your domain pretends they’re you or work at your company to trick someone into believing they’re you. They do this to steal personal data, such as login details or a credit card number.

2. It Helps You To Better Control Your Email Deliverability

Another perk of employing DMARC is that you’ll better control how many of your emails are legitimate and get to my recipients’ main inboxes. And if someone’s trying to impersonate you and send emails on your behalf.

3. It Protects Your Brand Reputation

If someone’s pretending to be you and trying to trick people into giving them money or some personal info, it reflects badly on your brand. DMARC helps to avoid that.

How Does DMARC Work?

DMARC specifies what has to happen for the message to go through to the inbox and what will happen if the conditions aren’t met. When DMARC is testing an email, 4 things might (or should) happen: 

1. DKIM pass: The additional signature in the header must be validated: the private key matches the public key published in DNS.

2. DKIM alignment: The parent domain matches the Header From the domain. 

3. SPF pass: The receiving server will take the domain included in the Envelope From address and check for an existing SPF record (and it checks if the IP address is included in the SPF record).

4. SPF alignment: The domain in Envelope From matches the domain in the email’s Header From.

A message will fail DMARC if it fails both SPF and DKIM. If you forward a message, only the DKIM stays aligned.

Aren’t SPF and DKIM Already Used to Protect Email?

The SPF and DKIM mechanisms both work to protect against unauthorized use. They work in isolation. There is no universal law stating what the receiver should do when such messages fail. Every receiver handles such failed messages differently. 

One receiver may redirect it straight away to the junk folder, while another will run additional tests to determine where it should go. Not to mention, the domain owner never gets any information about his emails and whether they reached the recipient’s main inbox.

DMARC & Rules

DMARC allows us to define our own rules on handling an email that doesn’t comply, reducing the risk of spoofing our domain. It also allows us to report back to the sender. Adding a DMARC record to DNS will allow you to set rules for the incoming emails: should they be quarantined, rejected, or let through?

DMARC Policies and Reporting

There are three possible DMARC policies:

1. None
2. Quarantine
3. Reject

DMARC & Policy

In email, this means that with a none policy, all the emails will go through, even if they don’t pass the SPF and/or DKIM test. With a ‘quarantine’ policy set up, the ones that don’t pass will be redirected to the spam folder. And with a ‘reject’ policy, they’ll bounce. 

A couple of days after you publish a DMARC record in DNS, you’ll start getting reports from ISPs. Those will include stats about all emails sent from your domain (including those that claim to come from your domain). If you see more emails than you’ve sent, someone else is using your domain.

Reports & Health

The report will give you an overview of where the emails come from and if they’d be halted by a “quarantine” or “reject” policy. These reports will allow you to assess the health of your outgoing messages. What elements do they include? 

How were the messages handled (in line with the DMARC policies that have been set up), IP addresses that have used your domain to send emails (as well as how many messages have been sent), and SPF and DKIM results? The reports can be read with a tool such as Postmark or dmarcian.

How to Set Up DMARC?

• Set up SPF and DKIM First things first. You must ensure your SPF and DKIM records are set up. If you’ve thought about your deliverability before, chances are you’ve already crossed that off my list. 

• Generate a DMARC record. For now, choose the ‘none’ policy for all emails.

• Add your DMARC record to DNS 

• Modify the policy according to data as you go Analyze several reports you get, and once you know how to maneuver through the DMARC policies, switch from ‘none’ to ‘quarantine’ and later on to reject.

A Multi-Layered Approach

A combination of SPF, DKIM and DMARC is deemed to be the golden trio of email authentication. SPF and DKIM are better known and more widely used. Right now DMARC is more of a nice-to-have than a must-have, but this will probably change in the future as more and more people are setting it up for better domain protection against spoofing and phishing.

Start Buying Domains Now and Setup Your Email Infrastructure Today

Inframail revolutionizes cold email infrastructure by providing unlimited inboxes at a flat rate. The service helps agencies, recruiters, and sales development representatives scale their outreach efforts efficiently. Inframail provides Microsoft-backed email deliverability, dedicated IP addresses, and automated technical setup. Unlike traditional email providers that charge per inbox and leave users wrestling with technical configurations, Inframail streamlines the entire process.

Automation & Support

The service automatically:

• Sets up SPF, DKIM, and DMARC

• Offers dedicated email servers for each user

• Provides priority support 16 hours a day

Inframail handles the complex infrastructure setup so you can focus on reaching more prospects.

What Makes Inframail Different?

Inframail's email infrastructure tool provides an extensive email setup without technical headaches and per-inbox costs. You can buy domains and set up your email infrastructure today with Inframail. The service helps agencies looking to scale outreach, recruiters connect with candidates, and SDRs drive sales.

Related Reading

• Email Monitoring Software
• Soft Bounce Reasons
• Check Email Deliverability Score
• Soft Bounce vs Hard Bounce Email
• SalesHandy Alternatives
• GlockApps Alternative
• MailGenius Alternative
• MxToolbox Alternative
• Maildoso Alternatives