<spf> declare your smtp servers

spf explained

SPF is the abbreviation of Sender Policy Framework, an email authentication standard,
that lets you declare which are the smtp servers authorized to send emails for your domain.

It allows you to confirm the sender’s address and its relationship with the server that sent out the message.
If emails are sent with your sender domain, the recipient can identify if it has been sent from one smtp server that you recognize.

It’s recommended to configure it, because some recipients may reject your messages if spf is not set at all.

how to make spf work

There are two different approaches:

• a “soft” one (~all tag), that generates a “softfail” error if the message has been sent by a non declared server
• a “hard” one (-all tag), that generates a “fail” error if the message has been sent by a non declared server

The “soft” setup will produce less/no rejection by the recipients.
The “hard” one will cause some messages to be rejected if the server has not been declared or in some cases when the email has been redirected or sent through a mailing list.

The “hard” setup provides the destination mail server with more faculty to decide whether to accept the message or not, this is the approach that we suggest.

how to configure spf

SPF setup requires to know exactly which servers you use to send out email messages.

With RealSender, the TXT record of your domain (example.com) should contain the string
a:example.realsender.com        and look like this:

example.com   TXT   "v=spf1 a:example.realsender.com ~all" 

With HighSender, the TXT record of your domain (example.com) should contain the string
include:spf.realsender.com        and look like this:

example.com   TXT   "v=spf1 include:spf.realsender.com ~all" 

These tools will help you validate the configuration:
www.kitterman.com/spf/validate.html *
   retrieves SPF records for the specified domain name and determines if the record is valid
spf check online
   validates your email SPF settings sending an email message

* = external website link, will open in a new page

spf downsides

Even if everything is set correctly, the message verification may fail
if the email has been redirected (forwarded) or sent through a mailing list.

In these cases, to keep the email authentication consistent,
configure the dkim signature domain to be aligned with the sender’s From address.
See: email authentication advanced » <dkim> alignment for dmarc.

<spf> check online

1. send an email message to:

spf@tester.realsender.com

2. check online the SPF validation results:
   (it will take a minute to appear)

https://tester.realsender.com/spf

RealSender SPF check online will add a subject prefix, if the message has not been authenticated correctly:

!! spf-fail !!       the smtp server is not listed among the authorized ones
                      and the email should be rejected or discarded
!! spf-softfail !!   the smtp server is not listed among the authorized ones
                      but this case should be treated as a "softfail"  
!! spf-neutral !!    the SPF record specifies explicitly that nothing can be said about validity  
!! spf-none !!       the sender domain contains no information to authenticate the email  

Sometimes the information recorded at domain level is not correct/understandable.

!! spf-permerror !!  a permanent error has occurred (eg. badly formatted SPF record)  
!! spf-temperror !!  a transient error has occurred

SPF check is made against the “Mail-From” email address, that is hidden in the email headers.
Only the “From” email address is visible. If their root domains are different, this warning is displayed:

!! spf-diff !!       the "Mail-From" and the "From" root domains are different

If the message passes both SPF check AND SPF alignment check for DMARC (relaxed alignment), you will get:

|OK| spf-pass        your email passes SPF check + SPF alignment check

If only one, SPF OR DKIM, passes the alignment check for DMARC (relaxed alignment),
the message is still considered “OK” (trusted) and the ~ (tilde) symbol is added at the beginning:

|~OK| spf-pass       your email passes SPF check (not the alignment) + DKIM alignment check

<dkim> seal the email content

dkim explained

DKIM is the acronim of DomainKeys Identified Mail, an email authentication standard,
designed to guarantee that the email (including the attachments) has not been modified since the “signature” was affixed.

It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message.

Two keys are used: a “public” and a “private” key:

1. the “public” key, is published in the TXT record of the signing domain
2. the “private” key, is saved whithin the smtp server and used to “sign” the email messages

While sending a message, the smtp server generates an “encrypted hash signature”, based on the email message contents and the private key.

The recipient system can verify the signature in the email header, comparing it with the email content and the sender’s “public” key.

how to make dkim work

DKIM signatures are not immediately visible to end-users, they are added and verified by the email infrastructure.

RealSender smtp servers sign all outgoing email messages with the dkim signature.

how to configure dkim

RealSender initially signs all outgoing messages with its own domain connected to the smtp server,
no setup is needed on the user/administrator side.

To get the “dkim domain alignment for dmarc”,
the message must be signed with the same domain of the sender.

With RealSender, you should add two CNAME records
in the dns settings of your domain (example.com), like these ones:

key1._domainkey.example.com   CNAME   key1._domainkey.yourcompany.realsender.com
key2._domainkey.example.com   CNAME   key2._domainkey.yourcompany.realsender.com

This tool will help you validate the configuration:
toolbox.googleapps.com *

* = external website link, will open in a new page

dkim downsides

A dkim sealed message can’t be modified, but it still can be read by anyone.

A signed message that does not pass the verification, usually gets rejected.
If no changes have been made along the way from sender to recipient, this should not happen.

We’ve experienced rare cases, all related with lines lenght (it must be max 990 characters).
Some applications send the content all in one line or transmit a very long line within the html.
On these occasions the dkim signature gets corrupted, causing the “dkim=fail” check result.

<dkim> check online

1. send an email message to:

dkim@tester.realsender.com

2. check online the DKIM validation results:
   (it will take a minute to appear)

https://tester.realsender.com/dkim

RealSender DKIM check online will add a subject prefix, if the message has not been signed correctly:

!! dkim-none !!      no DKIM-Signature headers (valid or invalid) were found  
!! dkim-fail !!      a valid DKIM-Signature header was found, but the signature 
                      does not contain a correct value for the message  

Sometimes it’s not possible to execute the check:

!! dkim-invalid !!   there is a problem in the signature itself or the public key record. 
                      I.e. the signature could not be processed
!! dkim-temperror !! some error was found which is likely transient in nature, 
                      such as a temporary inability to retrieve a public key

When the message has been signed using a different domain, a “diff” alert will be added to the subject.
This warning will NOT be displayed if the sender passes the SPF check and SPF alignment for dmarc:

!! dkim-diff !!      the message has NOT been signed by the sender's domain

If the message passes both DKIM check AND DKIM alignment check for DMARC (relaxed alignment), you will get:

|OK| dkim-pass        your email passes DKIM check + DKIM alignment check

If only one, DKIM OR SPF, passes the alignment check for DMARC (relaxed alignment),
the message is still considered “OK” (trusted) and the ~ (tilde) symbol is added at the beginning:

|~OK| dkim-pass       your email passes DKIM check (not the alignment) + SPF alignment check

<spf> alignment for dmarc

spf domain alignment for dmarc

DMARC is an email authentication standard, developed to combat spoofed domain mail.
For domain alignment it requires that:

   when a sender authenticates their email using SPF and/or DKIM,  
   at least one of the domains must align with the sending From domain

To get it within SPF (Sender Policy Framework), you deal with two domains:

• the sending From address, that is visible to the recipients
• the Mail-From address (also called “envelope sender” or “return-path”), that is hidden

DMARC allows two types of SPF alignment: relaxed alignment and strict alignment.
If you do not specify strict alignment, relaxed alignment is assumed as the default.

relaxed alignment

With relaxed alignment, only the root domain of the Mail-From address must match the root domain of the From address.
Relaxed alignment allows any subdomain to be used and still meet the domain alignment requirement.

example:

• if your Mail-From domain is mail.abc.com and your From domain is abc.com,
  your email will pass SPF alignment (the root domains “abc.com” match)

• if your Mail-From domain is abc.mail.com and your From domain is abc.com,
  your email will NOT pass SPF alignment (the root domains “mail.com” and “abc.com” do not match)

strict alignment

With strict alignment, the domain of the Mail-From address must match exactly the domain of the From address.

example:

• if your Mail-From domain is mail.abc.com and your From domain is mail.abc.com,
  your email will pass SPF alignment (the domains “mail.abc.com” match)

• if your Mail-From domain is mail.abc.com and your From domain is abc.com,
  your email will NOT pass SPF alignment (the domains “mail.abc.com” and “abc.com” do not match)

<dkim> alignment for dmarc

dkim domain alignment for dmarc

DMARC is an email authentication standard, developed to combat spoofed domain mail.
On domain alignment it requires that:

   when a sender authenticates their email using SPF and/or DKIM,  
   at least one of the domains must align with the sending From domain

To get it within DKIM (DomainKeys Identified Mail),
the dkim signing domain (DKIM-Signature: d=…) must match the sending From domain.

DMARC allows two types of DKIM alignment: relaxed alignment and strict alignment.
If you do not specify strict alignment, relaxed alignment is assumed as the default.

relaxed alignment

With relaxed alignment, only the root of the dkim signing domain must match the sending From domain.
Relaxed alignment allows any subdomain to be used and still meet the domain alignment requirement.

example:

• if your dkim sigining domain is mail.abc.com and your From domain is abc.com,
  your email will pass DKIM alignment (the root domains “abc.com” match)

• if your dkim sigining is abc.mail.com and your From domain is abc.com,
  your email will NOT pass DKIM alignment (the root domains “mail.com” and “abc.com” do not match)

strict alignment

With strict alignment, the dkim signing domain must match exactly the domain of the sending From address.

example:

• if your dkim sigining domain is mail.abc.com and your From domain is mail.abc.com,
  your email will pass DKIM alignment (the domains “mail.abc.com” match)

• if your dkim sigining domain is mail.abc.com and your From domain is abc.com,
  your email will NOT pass DKIM alignment (the domains “mail.abc.com” and “abc.com” do not match)

<dmarc> detects fake emails

dmarc explained

DMARC stands for: Domain-based Message Authentication, Reporting and Conformance.
It is an email authentication standard, developed to combat spoofed domain mail.

Senders:

• authenticate their emails with spf and dkim
• publish a “dmarc policy” for how to handle unauthenticated mail

Receivers:

• take action on unauthenticated mail, based on the sender “dmarc policy”
• report on the outcome to the sender

With some mailbox providers, it influences deliverability in a meaningful way, see:
How dmarc works with Google Mail and Office 365 in 2020 *
“Office 365 is generally responsive to spf and dkim authentication.
The only way to get consistent results, reaching the inbox, is to associate them with dmarc”

* = external website link, will open in a new page

how to make dmarc work

DMARC uses SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Emails)
to control the situation when email fails authentication tests.

SPF requires that you declare which servers you use to send out email messages.
Check how to configure spf to know more and set it correctly.

RealSender smtp servers sign all outgoing email messages with the DKIM signature.
A setup is needed if you want to sign with the same domain of the sender.
Check how to configure dkim to know more.

RealSender provides you a mailbox that collects the dmarc reports generated by the receivers.

how to configure dmarc

1. At the beginning you should set the policy tag to “none” (p=none),
   which means that the Mailbox Provider won’t do anything with the spoofed/phished emails.
   You should add a TXT record on your domain (example.com), that should look like this:
   

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc.example@rsbox.com"

2. Starting from the next day, you will begin to receive the dmarc rua reports online.
   
   You might discover that you forgot to authenticate an email campaign that’s being deployed from a third party.
   If something like that happens, simply authenticate it and check that the next mailing passes the dmarc tests.

3. When the reports are correct for a few weeks, tell the Mailbox Providers to reject/block those spoofed/phished emails.
   
   The _dmarc TXT record of your domain should be changed to look like this:

"v=DMARC1; p=reject; rua=mailto:dmarc.example@rsbox.com"

dmarc downsides

If your organization implements dmarc, you will need to check carefully
before you introduce any new method of sending email.

Dmarc applies strict policies on how spf and dkim are tested
this can cause emails which would otherwise pass those tests
to be rejected by mailbox providers.

Even if everything is set correctly, the verification may fail:

• the spf check, if the email has been redirected (forwarded) or sent through a mailing list
• the dkim check, if the message has been altered, breaking the dkim signature

<dmarc> rua reports online

RealSender collects and analyses the dmarc rua(*) reports for you.

* = rua meaning:
Reporting URI(s) for aggregate data. 

In RealSender, the “rua” is the email address provided to the customers,
to which aggregate reports are sent by domains
that have received mail claiming to be from your domain.

The reports are generated every day at 13:00 (CET) and contain the data of the last seven days.

This is a dmarc online report, sample page: