Google says that this month gmail.com starts telling receiving servers to reject mail that claims a Gmail sender but came from elsewhere. Make your forms send from your own domain, with the customer's address in Reply-To, then test them.

The form that stops arriving

A visitor fills in your contact form with their name, their question and a gmail.com address. The website emails it to you, and many forms make that email appear to come from the visitor.

That way, pressing Reply goes straight to the customer. It has worked for years.

This month it is due to stop working for gmail.com addresses. Google has said it will change the published policy for gmail.com so that receiving servers reject mail claiming a Gmail sender that did not come through Gmail.

The visitor still sees a thank-you message. The enquiry never reaches you.

What DMARC is, briefly

DMARC is a short public record a domain publishes, telling receiving mail servers what to do with messages that claim to come from that domain but fail its authentication checks.

The checks are SPF, a list of the servers allowed to send for the domain, and DKIM, a signature the sending server adds to each message.

A form on your web server sending as someone at gmail.com fails both, because your server is not one of Google's. From this month, Google says, the gmail.com record will ask receivers to reject those messages.

Forms that are affected

The last is where most of the risk sits. A form set up years ago by a previous developer keeps working until the day it does not, and nobody looks at its settings until enquiries dry up.

Why nobody notices

The website hands the message to a mail server and reports success. Whether your mailbox later accepts it is invisible to the visitor and to the form.

The rejection notice goes back to the technical sender address, often a default account on the hosting server that nobody reads.

Many hosting control panels have a delivery report showing what was sent and what was refused, but someone has to know to look.

Depending on who handles your mail, some messages may be refused outright and others filed as spam. Either way, the enquiry is lost.

Some other large email providers have published strict policies for some time, so a form built this way may already have been losing messages from their users.

Your domain in From, the customer in Reply-To

Set the form to send from an address on your own domain, such as website or enquiries at your business domain.

Put the visitor's email address in the Reply-To field. Pressing Reply in your email program will still answer the customer.

Put the visitor's name in the subject line, so you can still see at a glance who wrote. Most form plugins have separate From and Reply-To settings, so the change is usually quick.

Choose a From address that someone reads. Customers sometimes reply to the confirmation they receive, and that reply should reach a person.

A worked example

A tent rental company puts up marquees for weddings, graduations and backyard parties, and June is the start of its busiest season.

Its quote form was installed five years ago. It emailed the office from whatever address each customer typed, so staff could answer with one click.

When the office manager read about the gmail.com change, she tested the form with addresses from several providers. A message from one provider that already publishes a strict policy never arrived.

Its rejection had gone to a default mailbox on the hosting account, which held two years of bounced enquiries that nobody had seen.

The form now sends from an address on the company's domain, through its own email account with a login, with each customer's address in Reply-To and their name in the subject.

Staff tested again with gmail.com and three other providers, confirmed that Reply answered the customer, and put a monthly test in the office calendar.

Make your own domain pass the checks

Sending from your own domain helps only if your domain's records say the web server may send for it. Otherwise the message fails your own checks instead.

Either add the web server to your SPF record, or have the form send through your real email account with a login, the same way your own email program does.

The second is usually more reliable. The form's messages then carry the same authentication as the rest of your email.

Test the form properly

Submit your own form with a gmail.com address, an address at another large provider and one on your own domain.

Check that each message lands in the inbox rather than spam, and that pressing Reply addresses the customer.

Check the confirmation the customer receives as well. It should come from your domain and reach their inbox.

Repeat the test after any change to the site, the host or your email provider.

Find out where the bounces go

Ask your host or developer where messages rejected from the website end up. If the answer is a default account nobody reads, have it forwarded to someone who does.

Old rejections there show which enquiries never arrived, and often include the customer's details. A late reply with an apology is better than none.

Keep the forwarding in place afterwards, so the next problem shows up within a day rather than a season.

The counter-case

Forms that already send from your own domain through an authenticated account need nothing more than a test.

A hosted form service may already handle this, and a test will confirm it. And a business whose enquiries arrive almost entirely by phone has less at stake, though its form still deserves to work.

For everyone else: send from your own domain, put the customer in Reply-To, and test with a gmail.com address this week.

Before the next enquiry

  1. List every form on the site that sends email.
  2. Check each form's From setting.
  3. Change From to an address on your domain.
  4. Put the customer's address in Reply-To.
  5. Send through your real email account where possible.
  6. Test with gmail.com and other providers.
  7. Find where rejected messages end up.

Step six is the only way to know. A form can look correct in its settings and still lose messages, and only a real submission, checked in a real inbox, shows what customers experience.

What SPF and DKIM records prove is covered in the question mark Gmail puts next to unverified senders.


Frequently asked questions

What is changing with gmail.com this month?

Google has announced a DMARC policy for gmail.com that will tell receiving servers to reject messages claiming a gmail.com sender that were not sent through Gmail.

Why would my contact form be affected?

Many forms send each enquiry using the visitor's address as the sender. A message from your web server claiming a gmail.com sender fails the checks, and under the new policy it would be rejected.

What should the From address be?

An address on your own domain, such as enquiries at your business domain, with the visitor's address in Reply-To so pressing Reply still answers the customer.

Will customers know their message failed?

No. The form shows its thank-you message as usual, and the rejection goes to a technical address on the server, often one nobody reads.

Do my domain's own records matter?

Yes. Your SPF record must allow the web server to send for your domain, or the form should send through your real email account with a login.

How should I test the form?

Submit it with a gmail.com address, another large provider and your own domain, then check each arrives in the inbox and that Reply addresses the customer.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Contact form set up years ago?

Send us the address of your form. We will test it with Gmail and correct its sending settings.

Start a Conversation