Topics in this area:
the minimum settings that are required
get full control over the reputation of your emails
control what happens to your emails
automatically checks the correct operation of the services every ten minutes
Topics in this area:
Sender Policy Framework introduction
validate your email SPF settings sending an email message
DomainKeys Identified Mail introduction
validate your email DKIM settings sending an email message
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.
There are two different approaches:
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.
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
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.
last updated on September 3, 2020
spf@tester.realsender.comhttps://tester.realsender.com/spfRealSender 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 occurredSPF 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 differentIf 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 checkIf 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 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:
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.
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.
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.comThis tool will help you validate the configuration:
toolbox.googleapps.com *
* = external website link, will open in a new page
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.
last updated on August 25, 2020
dkim@tester.realsender.comhttps://tester.realsender.com/dkimRealSender 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 keyWhen 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 domainIf 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 checkIf 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 checkTopics in this area:
SPF domains out of alignment may cause the DMARC check to fail
DKIM domains out of alignment may cause the DMARC check to fail
Domain-based Message Authentication, Reporting and Conformance
rua messages collection and daily dmarc reports generation online
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 domainTo get it within SPF (Sender Policy Framework), you deal with two domains:
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.
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)
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)
last updated on July 28, 2020
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 domainTo 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.
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)
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)
last updated on July 28, 2020
DMARC stands for: Domain-based Message Authentication, Reporting and Conformance.
It is an email authentication standard, developed to combat spoofed domain mail.
Senders:
Receivers:
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
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.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc.example@rsbox.com"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.
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"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:
last updated on August 25, 2020
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:
Topics in this area:
detailed reports per month, days, hours, hosts, sender email
emails' logs, Delivery Status Notifications (DSN), Successful delivery notifications
look into the email messages that have been sent to understand what's going on
RealSender offers detailed reports of each smtp server / outgoing emails activity.
The data are updated automatically every five minutes.
On request we can send a weekly summary by email.
Note: these errors are generated by unauthorized attempts to send emails through the server
RealSender lets you access via browser to the processed emails data:
The displayed data can be saved locally directly from the browser, or automatically registered at regular intervals (eg once a day), to keep a history.
May 31 06:26:22 rs336 v4V4QL1K030027: from=sender@yourcompany.com
May 31 06:26:25 rs336 v4V4QL1K030027: to=recipient@yourcustomer.com, dsn=2.0.0, stat=Sent (Message accepted for delivery)
May 31 08:58:04 rs336 v4V6w3jN001390: from=sender@yourcompany.com
May 31 08:58:05 rs336 v4V6w3jN001390: to=recipient@yourcustomer.com, dsn=4.0.0, stat=Deferred: 421 recipient@yourcustomer.com Service not available - too busy
May 31 09:02:03 rs336 v4V6w3jN001390: to=recipient@yourcustomer.com, dsn=4.0.0, stat=Deferred: 421 recipient@yourcustomer.com Service not available - too busy
May 31 09:12:42 rs336 v4V6w3jN001390: to=recipient@yourcustomer.com, dsn=2.0.0, stat=Sent (Message accepted for delivery)
May 31 10:00:22 rs336 v4V80L9Z004176: from=sender@yourcompany.com
May 31 10:00:24 rs336 v4V80L9Z004176: to=recipient@yourcustomer.com, dsn=4.7.1, stat=Deferred: 451 4.7.1 recipient@yourcustomer.com: Recipient address rejected: Greylisting in effect, please come back later
May 31 10:02:03 rs336 v4V80L9Z004176: to=recipient@yourcustomer.com, dsn=4.7.1, stat=Deferred: 451 4.7.1 recipient@yourcustomer.com: Recipient address rejected: Greylisting in effect, please come back later
May 31 10:12:04 rs336 v4V80L9Z004176: to=recipient@yourcustomer.com, dsn=2.0.0, stat=Sent (Message accepted for delivery)
May 31 16:17:14 rs336 v4VEHCk6017038: from=sender@yourcompany.com
May 31 16:17:15 rs336 v4VEHCk6017038: to=recipient@yourcustomer.com, dsn=5.1.1, stat=User unknown
May 31 16:17:15 rs336 v4VEHCk6017038: v4VEHFk5017041: DSN: User unknown
May 25 12:43:37 rs336 v4PAhZw1019212: from=sender@yourcompany.com
May 25 12:43:38 rs336 v4PAhZw1019212: to=recipient@yourcustomer.com, dsn=5.0.0, stat=Service unavailable
May 25 12:43:38 rs336 v4PAhZw1019212: v4PAhcw0019217: DSN: Service unavailable
May 25 09:17:41 rs336 v4P7Hc6P011481: from=sender@yourcompany.com
May 25 09:17:42 rs336 v4P7Hc6P011481: to=recipient@yourcustomer.com, dsn=4.1.1, stat=Deferred: 452 4.1.1 recipient@yourcustomer.com 4.2.2 mailbox full
[…] the system retries the delivery every ten minutes* […]
May 25 13:25:47 rs336 v4P7Hc6P011481: to=recipient@yourcustomer.com, dsn=4.1.1, stat=Deferred: 452 4.1.1 recipient@yourcustomer.com 4.2.2 mailbox full
May 25 13:25:48 rs336 v4P7Hc6P011481: v4PBPko0020848: sender notify: Cannot send message for 4 hours*
* = see note at the end of the next paragraph
Bounced mails (eg user unknown) return to the sender’s email address or to the return-path address (if specified).
In the event of a delay in the delivery of the messages, you will receive a warning after 30 minutes*, like this:
Subject:
Warning: could not send message for past 30 minutes
Body:
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
[...] The system will automatically retry for four hours*. If you do not receive further notifications, it means that the messsage has been successfully delivered. You can check the details within the logs (see the above mentioned examples).
After four hours* unsuccessfull retries, a definite error will be returned to the sender’s email address or to the return-path address (if specified), like this:
Subject:
Returned mail: see transcript for details
Body:
The original message was received at ...
----- The following addresses had permanent fatal errors -----
<recipient@yourcustomer.com>
----- Transcript of session follows -----
Deferred: Connection timed out with yourcustomer.com.
Message could not be delivered for 4 hours
Message will be deleted from queue
[...] * = when sending bulk mailings:
delayed delivery status notifications are disabled,
the interval between the delivery attempts is increased (from ten to thirty minutes),
the maximum time of permanence in the queue is longer (from four to twenty-four hours)
On request, we can turn on the “delivery notification” for successfully delivered mails too. In this way, for each delivered message, the sender will receive the delivery receipt from the destination server. like the one below. This option is useful for those who need delivery receipts for each mail sent.
Subject:
Return receipt
Body:
The original message was received at ...
----- The following addresses had successful delivery notifications -----
<recipient@yourcustomer.com> (successfully delivered to mailbox)
----- Transcript of session follows -----
<recipient@yourcustomer.com>... Successfully delivered
[...]In rare cases (less than 1% of mails sent), the receipt is not released to the sender. This happens if the recipient has activated a special “privacy / noreceipts” option on his mailserver. This setting is generally not recommended as it also blocks the sending of standard non delivery notifications.
Sometimes, to understand what’s going on, it is necessary to examine the email messages that have been sent.
On request, RealSender may activate the automatic copy of all outgoing emails into a dedicated mailbox.
The mailbox is configured so that it can receive large amounts of emails in a short time with no hassle.
Email messages are automatically deleted after 7 days.
Pay attention: if the messages are sent from personal email accounts (even if they’re company’s accounts),
you need to inform the sender that the communications he sends can be read to perform technical checks.
To verify the correct functioning of the service,
we have activated an automatic control environment.
An external application connects to each SMTP server every ten minutes
and sends a real message. The successful sending of the email allows us to guarantee
the availability and correct functioning of the system.
The result is published on the “status page” of your RealSender server,
freely accessible at the web address: rsXXX-realsender.com/status
The data is displayed in real-time, such as the example data shown below.
The information shown is for the last twenty-four hours.
2024-09-11 06:25:26 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 06:16:18 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 06:05:56 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:55:41 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:45:57 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:35:58 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:25:27 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:16:30 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:05:57 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 04:55:36 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK