SPF to allow all servers in domain to send email

We recently got added an SPF record
  v=spf1 include:spf.protection.outlook.com -all

in our DNS, when migrating to office365 - however, the guys forgot that we send email from some additional in-house servers as well. Those emails now get rejected by SPF-aware recipients.

Our domain (let call it company-com) contains A records for our mail-sending servers srv1.company.com and srv2.company.com and we've got PTR records in place to resolve the servers ip addresses back to their names.
And now, of course, we need to fix the SPF record that was added to the DNS

As both srv1 and srv2 are listed with A-records in our domain, I thought that adding a "+a" would fix it:
  v=spf1 +a include:spf.protection.outlook.com -all

However, that doesn't seem to work. If I add "ip4: ip4:" (ip address to srv1 and srv2) it seems to work ok, but I'd rather not bind this to the ip addresses.

Isn't the +a method the correct way to do this?
Stefan LennerbrantAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Joshua GrantomSenior Systems AdministratorCommented:
just remove the plus(+). You may also want to make sure that your MX rcords are included in the SPF.

v=spf1 a include:spf.protection.outlook.com -all

Here is a good place to look at SPF syntax

Your usage looks fine.  But I might add ptr to it.

v=spf1 a ptr include:spf.protection.outlook.com -all

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

More on SPF:


You can also use MxToolBox to validate your SPF records:


Stefan LennerbrantAuthor Commented:
According to spec, a and +a are identical (the + is default)
I'll try, though.
I just changed to a:company.com, even though the "own domain" chould be default as well. Let's see that happens when DNS refreshes...
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

Stefan LennerbrantAuthor Commented:
I now note that the spec (openspf) says, for the A mechanism, that:
  All the A records for domain are tested. If the client IP is found among them, this mechanism matches.

Does this mean that a zone transfer is performed? And this that the DNS must allow zone transfers for the SPF "a" to be working? I don't find any information on that, though...
Stefan LennerbrantAuthor Commented:
@it_saige, yes using "ptr" seems to solve the problem.
However, openspf docs states that:
  If at all possible, you should avoid using this mechanism in your SPF record, because it will result in a larger number of expensive DNS lookups.

I had guessed that "a" would be the perfect mechanism to use - but, evidently, it does not work in my situation.
Could it really be a problem with zone transfers? Or what else would make "a" fail?
Stefan LennerbrantAuthor Commented:
Well changing to
  v=spf1 a:company.com include:spf.protection.outlook.com -all

did not solve the problem, but changing to
  v=spf1 a:srv1.company.com/24 include:spf.protection.outlook.com -all

fixed it.

Maybe I don't understand what "a" does check? From openspf I understood that all A records in the domain (that the mail claims to originate from) are checked and compared with the actual sending MTA.
However, it seems (?) like only the A record for "company.com" itself is checked?

With a:srv1.company.com/24 it works, as it seems like the receiving MTA looks up the A-record for the server srv1 (one of the mailing servers) and then allows all other servers on the same C-net (due to /24) which includes srv2

I cannot find any better documentation on that "a" mechanism really does. Any pointers to more reading?
I cannot imagine that it would be a problem with zone transfers.  One possibility is that you have mismatched IP's between where the mail is being sent from and where it is recieved to.

Check the outbound mail headers to see if the Received: from [xxx.xxx.xxx.xxx] matches the IP that is associated with your A records.

Stefan LennerbrantAuthor Commented:
I found a great tool at http://emailstuff.org/spf

  v=spf1 a:company.com include:spf.protection.outlook.com -all

this tool explicitly stated that (apart from outlook servers) only the ip address in the A record for "company.com" would be accepted for mail sending. Not any of the other A record ip addresses in the same domain

Thus, I understand that the "a" mechanism does not really take a "domain name" argument, but rather a "server name" argument (unless, of course, a domain name argument is further investigated with a zone transfer for all A records in the domain -- our DNS however does not allow zone transfers)

I really need to catch up on SPF syntax :-)

If someone could let me know if this issue (is it "domain name" or "server name" that is the argument to "a"), then I would be grateful...
Well according to the specification:

v=spf1 a:company.com include:spf.protection.outlook.com -all

Is synonymous with:

v=spf1 a include:spf.protection.outlook.com -all

Excerpt from www.openspf.org/SPF_Record_Syntax
"v=spf1 a -all"
The current-domain is used.

"v=spf1 a:example.com -all"
Equivalent if the current-domain is example.com.

"v=spf1 a:mailers.example.com -all"
Perhaps example.com has chosen to explicitly list all the outbound mailers in a special A record under mailers.example.com.

"v=spf1 a/24 a:offsite.example.com/24 -all"
If example.com resolves to, the entire class C of would be searched for the client IP. Similarly for offsite.example.com. If more than one A record were returned, each one would be expanded to a CIDR subnet.
Which is what leads me to believe that your A record points to one IP but the IP in the mail is comming from a different IP.

Stefan LennerbrantAuthor Commented:
@it_saige, your last two quotes are quite good. I saw them previously (on the net) while looking for input, but I obvisouly didn't really get it then...

With the "a:mailers.example.com" mechanism, I understood it such as that ALL of the A-records in the sub domain mailers.example.com would be allowed (like srv1.mailers.example.com, etc)
Instead, it seems more and more obvious that the "a" mechanism ONLY checks for the A record (or records) with the specific name "mailers.example.com" (which, to me, then is considered a server name, rather than a domain name)

Normally (right?), a company domain name by itself is used in an A record to complement the "www" server on the domain.
Thus, a simple "a" SPF mechanism will then only mean that the www webserver in the domain is allowed to send email.

Do you agree? If this is correct, I'd say that much info on the internet is a little confused on this matter :-)

The RFC 7208 however states this a little clearer (I'm sorry I didn't begin by checking this):
5.3.  "a"
   This mechanism matches if <ip> is one of the <target-name>'s IP
   addresses.  For clarity, this means the "a" mechanism also matches
   AAAA records.
      a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
   An address lookup is done on the <target-name> using the type of
   lookup (A or AAAA) appropriate for the connection type (IPv4 or
   IPv6).  The <ip> is compared to the returned address(es).  If any
   address matches, the mechanism matches.

This quite clearly states the the "target name" (the name following the "a:" - defaulting to the mail sender domain name) is looked-up in DNS for its A record. No other A records are looked-up.

So - if I've got an A record for company.com which is (which is the www web server, of course) and then an A record for srv1.company.com which is - then my "a" mechanism does not at all allow the srv1 server to send mail.

Much of the info on the net describes the "a" mechanism with something like the following, which seems to be completely wrong. Don't you agree?
In this SPF record, the “a” mechanism defines that all A records in this domain are permitted to send emails for this domain. The “mx” mechanism defines the same for all the MX records. The “-all” mechanism defines that everything else is not permitted. In most cases, that is what you need if you have a mail server that is just running for this domain.

At least myself am led to Believe, by such text, that ALL of the A-records in all of the domain, are allowed by SPF, with the "a" mechanism (just as is the case with the "mx" mechanism, which allows ALL of the MX servers)
However, all seems to indicate that ONLY the ip address (or addresses) in the A record for the domain name itself, is allowed...
I think you may be over complicating this which is leading to a tiny bit of confusion.

SPF works off the premise of reverse-lookup.  An SPF is not resolved until an email is received.  So using your scheme:

example.com DNS Zone file
A Record	Points To

CName Record	Points To
www		@

TXT Record
v=spf1 a -all

Open in new window

@ in this case simply means example.com.

Now, when an email is sent from example.com, the email has the ip address it was sent from in the headers.  When the recipient email server receives the email, it uses the IP in the email to see if it conforms to what is allowed by the SPF record.  In this case, it should not fail if the IP in the headers is either or as they are both A records that are registered in example.com's DNS zone.

Stefan LennerbrantAuthor Commented:
Nope, sorry - not as I see it, and have tested it.

With the sample zone that you describe above, emails sent from will not be allowed by SPF

The receiving MTA will see the "a" in the SPF record, and will lookup the A-record for the domain "company.com" (being specified as the domain name in the "MAIL FROM" email address)
This lookup will result in ip address

As this does not match the sending - the mail will not be allowed.

However, much info on the net does indicate, more or less, that ALL of the A-records (including in the domain will be checked and allowed by the "a" mechanism. But that is obvisouly not the case.
(and also, such a solution would need a costly and quite commonly disallowed zone transfer)
Stefan LennerbrantAuthor Commented:
...well, of course, the part with a zone transfer would not be needed if SPF would make a reverse-lookup on the ip address itself -- but that is what the "ptr" mechanism is for; and that mechanism is either recommended against or more directly specified as "depreceated"

So, in conclusion, the "a" mechanism only seems to check the A record for the domain name itself - it does not in any way allow any other hosts in the same domain (which of course have their own A records)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Stefan LennerbrantAuthor Commented:
FYI I just talked to some guys at MxToolbox, asking this (rather long:-) question:
You describe the “a” SPF rule as: “Match if IP has a DNS 'A' record in given domain”

This suggests that if a mail sending server is named mailsender.domain.com and contains an A record in the domain.com DNS, then the SPF rule matches.
Thus, with a domain.com DNS with the following A-records:

…then your “a” description for domain.com seems to mean that the mailsender ( would match the rule, just because that it exists as an A record in domain.com
However, this is (as far as I know) not correct. Or am I wrong?
I’ve been working quite a lot on such issues, and to my experience this is not the way the “a” rule works.

The SPF “a” rule for domain.com instead means (as I’ve understood it) that mail from any IP address that has an A record for the name “domain.com” (thus the @ record in the example above) matches.
To allow mailsender.domain.com, one must use an “a” rule that specifically identifies this particular host, or else declare a subnet like “domain.com/24” in the “a” rule, to allow all IP addresses in the same subnet as the address (the A record for @)

To my knowledge, this “misunderstanding” on how SPF “a” works, is quite common on the internet.
As you are such an authority on the matter, perhaps you could either tell me that I’m wrong :-) or else make some clarification in your SuperTool to avoid that people misinterprets the results.

I then got the answer below, clarifying that the "a" rule only mathces the A record for the domain itself, not all A records that exists in the whole domain
We mean that if the Ip is in the domain's A record then it matches. I'll forward this along to our engineering team to clarify the entry. Thanks for taking the time to let us know it's not confusing. Sometimes things make sense to us since we write them and not to anyone else.
Stefan LennerbrantAuthor Commented:
In particular, the response from the MxToolBox people (authorities on the matter) seems to settle this issue.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Email Protocols

From novice to tech pro — start learning today.