How to blacklist self-spam?

Self spam example


Spam sent with the same sender and recipient address is nothing new. In this article we will discuss what you as an administrator and ORF can do against these so called "spoofed" emails that appear to come from your own organization or someone you trust.

What is email spoofing?

Email spoofing is when someone forges the sender email address in an attempt to fool the recipient into believing that email is from a trusted source, such as your own or another reputable domain. This is a very common spam and phishing technique, made possible by the lack of any authentication mechanism of the core email protocols.

What can you do about it?

SPF Explained

SPF on Wikipedia (external link) (external link)

SPF Tools

Vamsoft SPF Syntax Validator
Vamsoft SPF Checker

The very first thing you ought to verify is whether your domain has a published SPF record. An SPF record is a TXT-type DNS record published by the domain administrator in the DNS zone file that states which hosts and IP addresses are permitted to send emails on behalf of the domain. It can be viewed by running the nslookup -type=txt command from the command line, where "" is your domain. If no TXT record is returned that starts with "v=spf1 ...", that means your domain name and its reputation can be freely abused by any person with ill intentions.

Publishing an SPF policy is usually very simple: if you have a single outbound mail server only, all it takes is adding a new TXT record to your DNS configuration with the text v=spf1 mx -all. This tells the world that only the server(s) listed in the MX record may send email in the name of your domain.

In case you have multiple outbound servers that are not covered by the MX record (e.g. emails are sent from your webserver or you use 3rd party services to deliver marketing emails in the name of your domain), then you will have to create a custom SPF record to include them. In that case, you should familiarize yourself with the SPF record syntax or use an online SPF record generator to create the appropriate policy.

Finally, make sure the SPF Test is turned ON in the ORF Administration Tool (Filtering > Tests).


When publishing an SPF policy and enabling the SPF Test, you should be absolutely sure that all outbound emails are whitelisted in ORF. See section Whitelisting Outbound and Authorized Emails for more information.

Still receiving emails spoofing your domain?

It is probably time to talk about a lesser known fact about emails. Namely, that an email can have two sender addresses:

The first one is called the (RFC5321.MailFrom) Envelope Sender Address, which remains hidden from view and is used by mail servers during the SMTP transmission. This is what ORF and your mail server logs and also what the SPF Test validates. It is also the address to which any undeliverable message notices, or bounce messages, are sent. You may find this address in the "Return-Path:" field of the message header. If we were to use an analogy, this is the sender address that you would write on an envelope for the post office to return your letter to in case it cannot be delivered for some reason.

The second one is called the (RFC5322.From) Display From Address, which is displayed by the email client (e.g. Outlook) when the recipient opens the email. This address cannot be and is not meant to be validated by the SPF Test (more on this below). This address can be found in the "From:" field of the message header. To continue the previous analogy, this would be the address of the actual author which would appear in the letterhead.

So how can we validate the Display From Address, since that is the email address which the recipients actually see?

Publish a DMARC policy for your domain

DMARC Explained

DMARC on Wikipedia (external link) (external link)


Vamsoft DMARC Policy Checker

DMARC is an email authentication protocol that builds on SPF and DKIM and can successfully thwart scam and phishing attempts. Emails that appear as though they were authored by someone from a domain protected by DMARC must pass the SPF and/or DKIM tests, and – and this is the key part – the domain identifier used for the SPF/DKIM verification must match the domain in the Display From Address.

To verify whether you domain has a published DMARC record, run the nslookup -type=txt command from the command line, where "" is your domain. Unless you receive an answer TXT record starting with "v=dmarc1 ..." you will need to create and publish a DMARC record for your domain.

Similarly to SPF, this is done within the DNS registrar of your domain by adding a specific TXT record under where "" is replaced with your domain name (or subdomain). The simplest DMARC policy you can use is v=dmarc1; p=reject or v=dmarc1; p=quarantine, which tells the world to reject or quarantine the email claiming to be from your domain if it fails the DMARC check.

More complex policies can be created manually (consult the official DMARC site) or using one of the many online DMARC policy generators.

Once you are done with the above, make sure the DMARC Test is turned ON in the ORF Administration Tool (Filtering > Tests).


Do not publish a DMARC policy until you confirm that your domain has a published SPF record and/or your emails carry a valid DKIM signature. Otherwise, DMARC-enabled mail transfer agents might reject emails coming from your domain.


DMARC does not address “lookalike” domain attacks (e.g. email coming from “” ), or display names abuse (e.g. when only the displayed username is spoofed, but the email address is not). To combat these kind of phishing attempts we suggest that you create the appropriate regex-type Keyword Filter expression with an "Email Header (raw MIME)" search scope in ORF.


Whitelisting outbound and authorized emails

There are two scenarios when an email is actually expected to arrive to your server in your name: when it is an internal email and when it is being submitted for relaying. Typically, you have nothing to do to whitelist these emails, because:

  1. ORF whitelists authenticated SMTP sessions and relaying is typically controlled by authentication. This whitelisting is enabled by default, but in any case check that the Authentication Whitelist test is enabled under Filtering > Tests page.
  2. ORF whitelists emails originated from the intranet. This is when you see the message "Email whitelisted (email from a trusted intermediate host or intranet)" in the log.
  3. ORF usually does not see internal email, because it filters the SMTP traffic only and Outlook + Exchange communicate with each other using a different protocol, MAPI.

However, if you have any emails that are not covered by the above three rules (e.g. you control relaying by IP instead of SMTP authentication), you will have to whitelist these authorized sources, e.g. by using the IP Whitelist. Here are a few examples of scenarios not covered:

Whitelist issues

If your domain is whitelisted, none of the above solutions will work. As whitelists take precedence over blacklists, this type of spam will get through. There are two typical cases:

TipFor more tips on fine-tuning ORF, check the Best Practices Guide.

hnp1 | hnp2