Your Webvanta site may generate emails for various reasons:
To minimize the chances of these emails being blocked as spam, there's a few things you should consider, as outlined below.
In your domain's DNS configuration, you should have an SPF (Sender Policy Framework) record. This is not strictly required, but it is an easy and important step in reducing the likelihood that mail you send, through normal means as well as from the website, is blocked as spam.
You should add the following to your SPF record, which authorizes Webvanta's email servers as senders of email that has a reply address with your domain name:
This is the IP address of the server that sends mail on behalf of the Webvanta system.
If you are using Google Apps to send your mail, then your complete SPF record would look like this:
v=spf1 include:_spf.google.com ip4:220.127.116.11 ~all
The first part authorizes Google's mail servers as a sender of email from your domain, and the ip4 entry authorize Webvanta's email server.
When someone fills out a form on your site, an email is generated (assuming the site is set to do so) to notify the site admin of the new submission. If the form includes a field named "email", the contents of this field are used as the "reply-to" address. This allows the recipient of the notification email to reply directly to the person who filled out the form.
The default "from" address is "email@example.com". (You can modify this, as described below.) Notification emails will appear to come from this address. When you reply to the notification message, however, the reply will be addressed to the email address from the form.
We use different values for the "from" and "reply-to" addresses to help prevent emails being rejected as unauthorized. Yahoo and AOL have made changes to their DMARC policy, which tells other mail systems that they should reject any mail with a "from" address at the Yahoo or AOL domains, if the message did not actually come from Yahoo or AOL. Because of this, reliable email delivery is impossible if the "from" address can be set by the user independently of what system the email is actually coming from.
If you use the standard contact form, when someone submits the form, they do not receive any email acknowledgement. For more control, you should use a custom form, connected to a custom item type.
If you create a custom form, you can specify whether or not the person submitting the form receives an acknowledgement, and what the reply-to address is. (See Creating Forms for User Submissions for details.) This address is specified as part of the form definition, and is not affected by the Global Settings discussed in this article. Be sure to use a valid email address, or emails sent with this reply-to address may be blocked as spam.
For user activation emails, password reset emails, and comment notification emails, the default reply-to address is
firstname.lastname@example.org (except for sites created by private-label partners, as described in the following section). You can override this and set a specific address as the "from" address by creating a Global Setting named
admin.form.from.email and setting its value to the desired reply-to address. Make sure this is a valid email address.
If you are a design partner and have set up a custom master domain name, so your in-development sites are at a domain name such as
sitename.yourdomain.com, then any messages that would normally have a reply-to address of
email@example.com will instead have a reply-to address of
If you are using this setup (that is, you have a custom master domain name and you are not explicitly setting the reply-to address as described earlier in this article), then you should ensure that you have an email server at the domain name you are using for your master domain, and create an email account with the user name "no-reply". Otherwise, some email servers will reject email that comes from the website, because they will check to see if the reply-to address is a valid address.
For form submit notifications, you can customize the subject lines in the form setup (through the custom item type being used for the form data).
You can use WebvantaScript in the subject line, which is often useful to include contents from the form fields. For example, suppose there are "name" and "product_interest" fields in the form. This code:
<w:kb:item>Product inquiry regarding <w:product_interest /> from <w:name /></w:kb:item>
will create a subject line "Product inquiry regarding (product interest) from (name)".
For password reset emails, you can customize the subject lines by storing the desired subject line in the following configuration settings:
admin.user.email.forgot_password— for "Lost Password" requests made by the user, by clicking the link on the login form.
admin.user.email.forgot_password_admin— for password resets initiated by a site admin, though the People control panel.