|
To combat the phishing problem, SPF is changing the
way email is sent. SPF was designed to be transparent
to most segments of the industry. But outsourced email
service providers --- companies who send mail on behalf of
other companies --- may need to make a few changes.
These instructions are intended for services like Digital
Impact, Constant Contact, and any other email service
providers who are contracted to send legitimate bulk
marketing email.
This can look like a forgery.
Return-Path: <bounces@BigCompany.com>
From: Big Company <bounces@BigCompany.com>
Subject: Big Company announces Big Savings!
|
This just looks suspicious.
Return-Path: <bounces@ESP123.com>
From: Big Company <bounces@ESP123.com>
Subject: Big Company announces Big Savings!
|
This is technically OK but still suspicious.
Return-Path: <bounces@bigcompany.ESP123.com>
From: Big Company <info@bigcompany.com>
Sender: <bounces@bigcompany.ESP123.com>
Subject: Big Company announces Big Savings!
Precedence: bulk
|
This is best.
Return-Path: <bounces@ESP123.bigcompany.com>
From: Big Company <bounces@ESP123.bigcompany.com>
Reply-to: <unsubscribe-123456@ESP123.bigcompany.com>
Subject: Big Company announces Big Savings!
Precedence: bulk
|
|
Under the rules of Sender ID, the first example is
considered a forgery. This is because the mail comes from
your servers, not BigCompany.com's. BigCompany.com is
identified as the sender, but unless their SPF record points
to you, SPF won't pass. (For really big companies, contract
senders are too numerous and too volatile to include in the
top-level SPF record. Smaller companies with only one or
two contract ESPs might get away with a simple SPF
inclusion.)
You could just use your domain name (esp123.com) in all
the headers, but then the client's domain name won't show up
anywhere, and now your mail looks like a phishing attack.
This is not recommended.
Strictly speaking, Sender ID requires only that the
Purported Responsible Address match the sending client's IP.
If the client really wants their main domain name to appear
in the "From" header, you can put your domain into the
"Sender" field.
The best solution is for you to get the client
(BigCompany.com) to delegate a subdomain for you
(esp123.bigcompany.com). They have asked you to send mail
on their behalf. A delegated domain name explicitly
reflects this relationship. And it puts you in control.
Yes, bigcompany.com will have to allocate a subdomain and
get their DNS admins to delegate it. This is more work for
them and for you. But that's exactly why it's worth doing:
a phisher can't get that delegation from them. You can.
|
And remember to add a Precedence header! That will
prevent "out of the office" autoreply messages from going to
your bounce handler and accidentally unsubscribing someone
who should still be on your lists.
|
