Sending messages from my server give a via in the from line

SPF records need to be on the actual domain name being used in the email. So if you're sending mail from @example.com, you have to have a TXT record* on example.com - you don't want it on spf.example.com. You should be able to check your record with "dig txt example.com" or "dig spf example.com".

You should also ensure you leave enough time for DNS propagation to the receiving system doing the SPF lookups. (During testing, I'd set a low TTL on your SPF records as you may be updating)

And just to check - are "a" and "mx" appropriate for your server? E.g., does the domain in your email resolve (via A or MX records) to the IP address of your server?

Not sure what other providers may do it, but assuming the "Via" comment is in regard to GMail, view the original text of the message in question and look for the Received-SPF: header line. It should be a pass if matching your SPF record. If not, there are various SPF testing tools on the web (such as <url url="http://www.kitterman.com/spf/validate.html">http://www.kitterman.com/spf/validate.html</url>) that you can use to test - just be sure to specify the domain that is being used on your outgoing mail.

If none of this seems to help, post more detailed information, including specifics of your Linode's IP address and the From address your using in your message - some sample headers from the receiving side would work. This is a case where obscuring your information makes it impossible to verify, plus it's not like this isn't information the whole world is seeing already anyway.

– David

*   It's also recommended to have an SPF record, and I do, but in practice I see very little queries to it over TXT.</r>

David-

Thank you for the very thorough response. It is very helpful.

When I run the dig command I am not seeing my SPF record in there, which was confirmed by using the tester on kitterman.com.

It's been almost a week since I made the SPF change, but I made some changes to my zone file today and set a lower TTL for further testing.

I do have MX records in my zone file, but I do not think they should be in there. They were copied from another one of my domains, that is using a Google apps account for e-mail.

The "Via" comment is in regard to GMail.

I am trying some things out (waiting on the domain propagation), so I will report back how it works out.

Thanks again, and I will keep you posted.

@cyphun:

It's been almost a week since I made the SPF change, but I made some changes to my zone file today and set a lower TTL for further testing.
Just to double check - the way you phrased things in your first post, you have the wrong record in your domain, thus my initial comments about where the SPF record has to be put. So is that what you've changed?

In other words, from your first post:

> Just to be clear, I created a TXT record with the name "spf" and the value of "v=spf1 a mx ~all" with the default TTL.
the bold portion (added by me) is wrong. In other words, if your domain is example.com, the above sounds like you created an SPF record at spf.example.com, when it should have just been example.com.

– David

I got my SPF record updated, but I am still having my initial issue.

I should probably re-explain myself, because I don't think I did a good job with it at first. When I receive e-mail from my server in GMail they come to me like this:

Cyphun via li89-90.members.linode.com

I would like them to come to me like this:

Cyphun via cyphun.com
or
Cyphun

The updates I made during my last post are working, in that the kitterman.com can see my SPF record, but GMail still says via li89-90.members.linode.com. Here is a copy of kitterman.com result:

SPF records are primarily published in DNS as TXT records.

The TXT records found for your domain are:
v=spf1 a mx ~all 

SPF records should also be published in DNS as type SPF records.
No type SPF records found.

Checking to see if there is a valid SPF record. 

Found v=spf1 record for cyphun.com: 
v=spf1 a mx ~all 

Thanks for the help, any ideas on what to do next?

There is no quick fix for the Gmail "via" issue. It's probably an anti-phishing measure, and only Google knows exactly what triggers it. (This may or may not be related to the "on behalf of" issue, which is triggered by a "Sender:" header.)

See http://support.google.com/mail/bin/answ … er=1311182">http://support.google.com/mail/bin/answer.py?hl=en&answer=1311182

If you're sure your SPF is correct and you're still seeing the "via" thing, you might want to try DKIM next -- but that can be quite tricky.

Or you can just change your mail server's hostname to something like mail.cyphun.com. (Also make sure that you have a valid A record for mail.cyphun.com that actually points to your IP address. It won't hurt to add it to your SPF record, too.) That way, your mail will show up as "Cyphun via mail.cyphun.com", and if Google is clever enough, it will recognize that the "via" is no longer necessary since the domain is the same.

@cyphun:

I got my SPF record updated, but I am still having my initial issue.
You may still have a mismatch between the SPF and the actual domain used in the message. What address are you using as the "from" in your email at the transport layer? cyphun.com or something else like mail.cyphun.com?

It would help if you could post a full set of headers from one of your received messages (use "show original" in GMail and copy the header portion).

In particular, check the "Return-Path" header as it should reflect the domain the SPF lookup is being done for. And Google adds a Received-SPF header with details about the SPF lookup. In my experience a passing SPF header won't show the "via".

– David

Here is a header from an e-mail that I was testing this afternoon:

Delivered-To: cyphun@gmail.com
Received: by 10.52.26.12 with SMTP id h12cs28330vdg;
        Thu, 2 Feb 2012 13:29:43 -0800 (PST)
Received: by 10.14.28.142 with SMTP id g14mr1258111eea.86.1328218182682;
        Thu, 02 Feb 2012 13:29:42 -0800 (PST)
Return-Path: <apache@li89-90.members.linode.com>
Received: from li89-90.members.linode.com (li89-90.members.linode.com. [74.207.247.90])
        by mx.google.com with ESMTPS id y10si2239384eeh.166.2012.02.02.13.29.41
        (version=TLSv1/SSLv3 cipher=OTHER);
        Thu, 02 Feb 2012 13:29:42 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of apache@li89-90.members.linode.com designates 74.207.247.90 as permitted sender) client-ip=74.207.247.90;
Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of apache@li89-90.members.linode.com designates 74.207.247.90 as permitted sender) smtp.mail=apache@li89-90.members.linode.com
Received: from li89-90.members.linode.com (localhost.localdomain [127.0.0.1])
    by li89-90.members.linode.com (8.13.8/8.13.8) with ESMTP id q12LTd2j006156
    for <cyphun@gmail.com>; Thu, 2 Feb 2012 13:29:39 -0800
Received: (from apache@localhost)
    by li89-90.members.linode.com (8.13.8/8.13.8/Submit) id q12LTdVk006155;
    Thu, 2 Feb 2012 13:29:39 -0800
To: cyphun@gmail.com
Subject: DragonVale Breeding Database - Welcome
From: Cyphun <no-reply@cyphun.com>
X-Mailer: CakePHP Email
Date: Thu, 02 Feb 2012 13:29:39 -0800
Message-ID: <4f2b0043437045b395270a7c4acff75a@dev.dragonvale.cyphun.com>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit</no-reply@cyphun.com></cyphun@gmail.com></apache@li89-90.members.linode.com>

You need to set your rDNS.

Go to your Linode > Remote Access > Public IPs (Reverse DNS)

Do a lookup for the domain you wish your ip to resolve to. You will then have the option of setting it as the reverse DNS for an IP. (namely, the IP the domain resolved to)

I will give that a try. Just waiting for the settings to propagate, and then I will let you know if that works.

Thanks.

@cyphun:

Here is a header from an e-mail that I was testing this afternoon:
Ok, I suspect it's the fact that your mail is using the members.linode.com address in the SMTP envelope (see return-path), and thus, that's the one that the SPF lookup is processing. So your SPF records are not coming into play. As things currently stand, you'd need an SPF record for li89-90.members.linode.com - whose DNS you can't control.

GMail is applying a "best guess" SPF processing, based on the fact that the mail originated from the IP address that a lookup on li89-90.members.linode.com returned. But that's not due to actually finding an SPF record in DNS. Plus, your envelope address domain doesn't match your From: header. (That's not required technically, but nowadays I wouldn't be surprised if that came into the equation, perhaps especially if the SPF part was "guessed").

I think your next step is to test while ensuring that the envelope domain you are using is one that provides an actual SPF record. To be even more bullet proof, I might suggest keeping your envelope domain in sync with the domain used in the From: header on each message, but that may or may not be easy to do with your mail generation.

So for example, try to generate a message with both an envelope and From: header of "no-reply@cyphun.com", or at least get cyphun.com or some other domain you can create an SPF record for into the envelope. Your existing SPF record for cyphun.com permits your Linode's IP address (via the "a" lookup of cyphun.com), and everything should match and SPF pass.

I don't think rDNS was involved in this issue so far, though of course you can adjust your official hostname to whatever you want, at which point you should keep it in sync with rDNS. But for the purposes of mail generation, it's reasonably common for the reverse lookup of the sending server to be some other name than the domain of the email envelope (e.g., a "mail.example.com" host generating mail for "@example.com" users). Of course, changing your hostname is also an easy way to control the envelope, since presumably your current mail generation is going to use "apache@xxxx" where xxxx is whatever you configure your Linode's hostname to be.

– David

I updated the rDNS setting to my main domain, and now the via thing is totally gone, which is awesome.

David, thank you so much for replying with very helpful and thorough responses. You were a ton of help! Thanks to derfy and everyone else as well who helped out.