Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're using an email sending service (fairly known) to send our emails. We made DNS changes so that emails going through them would pass SPF and DKIM.

A few days ago we noticed that they allow any account with them to send emails on behalf of domains that do not belong to that account. For example, let's say my domain is, and now I want to add to my account. This service would now allow me to send emails from

I brought this up with them and their solution was to no longer "sign" the email, but still allow me to add whatever domain I want. So now I can still send from except that Gmail, for example, would show "via". SPF and DKIM would still pass, and the email is not marked as spam.

So, am I being paranoid? I feel that using this email service it would allow anybody with an account to send emails that sort of look like they come from us.

They argue that this is "standard practice" and that anybody with a box somewhere could do the same. But, would SPF/DKIM still pass in those cases?

I feel that by making DNS changes I authorize this email sending company to send emails on my behalf, and then the company goes ahead and allows anybody with an account to send on my behalf (without the signing part); am I off?


share|improve this question
up vote 6 down vote accepted

SPF on your domain is not about preventing you from sending forged emails; it is about preventing other people from sending emails with your domain. To be more precise, if you own domain, you can document in SPF that "every email which purports to come from an address should exit from machine and none other". Email servers who receive an email with an alleged sender with an address may then lookup the SPF records and check whether the email seems to come from the legitimate server (yours) or some other.

SPF processing is not mandatory so it is up to each email server to enforce it, at their leisure.

The SPF records on your domain ( will not prevent you from sending an email with a fake address, e.g. an address ending with In that case, it would be the SPF records on the domain which matter.

DKIM has a somewhat similar goal. When your server uses DKIM, then it signs every email that goes through it. The DNS for your domain documents that fact, and publishes the public key (the one used to verify the signature). Supposedly, when an email server receives an email with an sender, that server will see your DKIM key in the DNS, and thus verify the signature. If the signature is absent or does not correspond to the mail contents, then the receiving email server will know that something is amiss.

There again, DKIM processing is up to each email server. And, there again, nothing in your domain will prevent you from sending emails with as alleged sender -- but if the owner uses DKIM himself, your forgery will be revealed.

Summary: the DNS rules related to SPF and DKIM, added to the domain, document how an email should normally be sent/signed when it pretends to be sent by someone with an address. The DNS rules in tell nothing whatsoever about emails which claim to originate from another domain.

share|improve this answer
Using your example, I authorize this service (X) to send emails from Now some bad guy comes along, makes an account with X, and adds as their domain. They can now send emails that look like except for the signing part (shows up as "via" in Gmail). Could the bad guy have done the same without X's help? – pbz Apr 9 '13 at 20:29
"Authorizing" the "X" service to send emails from means adding in the DNS records of the information: "under normal conditions, an email bearing sender's address can exit from X". This "allows" X to send mails in your name; or, more accurately, it forbids all other people except X from sending mails in your name. But it does not help against forgeries from X itself. – Thomas Pornin Apr 9 '13 at 20:57
Exactly, so their "anybody with a server can do this anyway" argument is not valid, correct? – pbz Apr 9 '13 at 21:06
SPF and DKIM are exactly meant to prevent "anybody with a server" to do the same, indeed. Since SPF and DKIM are not mandatory (yet), forged emails still exist, but if X does what you describe, then X is misbehaving (X does exactly what SPF and DKIM were designed to prevent: sending emails with forged sender addresses). – Thomas Pornin Apr 9 '13 at 21:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.